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ABSTF  ACT 


This  volume  presents  System  Concepts  and  System  Use;  it 
shows  a sample  NIPS  ?60  FFS  Data  File,  the  Glossary  of 
Terms,  and  a description  of  the  NIPS  350  FFS  Data  Pile  and 
File  Format  Table. 

The  NIPS  360  ia  the  to:  al  system  composed  of  the  S/360 
hardware  and  S/360  Operating  System  (OS)  used  to  support 
NIPS  360  FFS  software. 

This  document  supersedes  CSB  UN  15-74  , Volume  I. 

CSN  UH  15-79,  Volume  I is  part  of  the  following 
additional  NIPS  360  FFS  documentation: 


CS1  UN  15-78  Vo  1 IT 
Vo  1 III 
Vol  IV 
Vol  V 
vol  VI 
Vol  VII 
Vol  VIII 
Vol  IX 

TR  3 V -78 
CSN  GD  15-78 
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SECTION  l 

INTRODUCTION 


This  volume  is  divided  into  five  sections.  Section  1 
presents  a general  introduction  of  the  concepts  and 
applications  of  the  NIPS  360  Formatted  File  Systen, 

Section  2 discusses  t h?  concepts  of  data  storage  in  a 
fomatted  file,  the  lathods  used  for  data 

validation/conversion,  and  the  general  language 

specifications  employed. 

Section  3 discusses  the  method  by  vhich  the  systen 
oparatas  and  procedures  used  in  developing  the  data 
validation /conversion  routines  vhich  are  defined,  by  the 
usar  for  specific  file  applications. 

Section  4 defines  a sample  data  file  vhich  will  be  used 
in  examples  throughout  the  system  documentation. 

section  5 contains  a glossary  of  terms  used  in  the 
doc  umentation. 

Appendix  A contains  a detailed  explanation  of  the 
physical  layout  of  NIPS  360  FPS  data  set  vhich  is  the  user's 
J a ta  file. 


Appendix  B contains  a description  and  use  of  the 
transaction  records  output  by  the  file  analysis  statistics 
capability . 


l.L  System  Components 

Tha  NIPS  360  FF3  is  made  up  of  several  relatively 
independent  components,  each  of  vhich  performs  a function  in 
relatioa  to  data  files  of  the  system.  The  total  complex  of 
components,  working  together,  provides  the  user  with  the 
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ability  to  perform  the  complex  file  processing  job  required 
in  modern  information  management  systems.  Although 
comprehensive  descriptions  of  each  of  the  components  are 
presented  in  the  appropriate  volumes  of  th»  NIPS  ^60  FFS 
Usits  Manual,  a brief  introduction  to  each  is  included  in 
this  section,  since  reference  is  made  to  the  components  in 
establishing  the  file  processing  and  languaye  rules  covered 
in  this  document. 

a.  tii.i_Stc.uc  tur  i ng._i?  S j Component  - This  component 

establishes  the  necessary  communications  media 
required  by  the  balance  of  the  system  n data  file 
processing.  This  communications  media  is  called 
the  File  Format.  Table.  Simply  stated,  a tabular 
array  of  the  essential  attributes  of  each  of  the 
user-described  data  elements  is  created  by  the 
component.  This  array  is  stored  as  part  of  the 
data  file  and  is  accessed  by  the  other  components 
when  processing  user  language  statements. 

b.  File  Maintenance,  (PM),  Component  - This  component 
generates  and/or  updates  the  user's  data  files. 
Several  user  languages  are  provided  which  permit 
the  analyst  to  specify  data  validation  procedures. 
Logical  data  examination  and/or  manipulation,  and 
summarization.  Although  the  normal  output  of  the 
process  is  a data  file  in  updated  form,  the  analyst 
may  request  additional  "auxiliary"  output  files 
which  ace  created  as  a by-product  of  the 
maintenance  function. 

c.  Retrieval  and  Sort.  Processor  (RASP{  - The  Retrieval 
component  is  an  analytical  tool  used  to  extract 
information  from  one  or  more  data  files.  This 
component  has  the  capability  to  sequence  the 
extracted  information  in  a variety  of  ways 
determined  by  the  requirements  of  the  final  output 
report  to  b°  produced. 

d . Output  Processor  (OP) Component  - This  component  is 

used  for  formal  report  production  and  provides  a 
convenient  method  of  listing,  summarizing, 
formatting  and  counting  data  elements.  Control 
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mechanisms  are  provided  which  permit  preparation  of 
reports  of  extremely  complex  structure.  The  data 
source  used  in  this  report  production  way  be  either 
a data  file,  or  the  answer  set  produced  by  the  RASP 
cow  pon  ea  t . 

?.  Terminal.  Processing  • This  component  is 

actually  composed  of  three  major  subsets  in  the 
current  version  of  the  system.  The  first  is  the 
programs  requited  to  interface  with  the  graphic 
display  devices.  As  such,  the  system  user  is 
relatively  unaware  of  its  existence.  The  second  is 
the  Quick  Inquiry  Processor  (QUIPI  , which  provides 
the  user  with  the  capability  to  interrogate  data 
bases.  Functions  performed  are  similar  to  those 
performed  by  RASP  and  DP.  This  capability  Bay  be 
utilized  from  the  bitched  job  stream  as  well  as 
from  terminals.  The  third  major  subset  of  this 
component  is  Source  Data  Automation  (SODA)  which 
provides  the  capability  of  maintaining  data  files 
from  terminals.  Input  data  may  be  edited, 
corrected,  and  processed  with  prestored  FM  logic 
statements . 

f.  Utj,l  ;t y Su ppoct  ( UT)  Programs  - This  is  a 
collection  of  general-purpose,  utility  programs 
which  lay  be  utilized  by  the  analyst  in  the 
performance  of  his  job.  Significant  among  the 
varied  capabilities  provided,  is  the  data 
conversion  function  accomplished  by  a set  of 
programs  cf  this  component.  This  capability 
provides  the  simple  and  aliost  automatic  method  by 
which  the  user  analyst  Bay  directly  convert  a 1410 
NIPS  data  base  to  NIPS  360  format. 

Each  component  mentioned  above  is  discussed  in  detail  in  a 

separate  volume  of  this  manual  (see  listing  in  the 

A bstract ) . 
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1,2  Interrelation  of  Components 

because  of  the  flexibility  of  the  syste®,  it  is 
iifficult  to  establish  specific  relationships  between  the 
various  components.  The  following  logical  flow  of 
information  through  the  syste®  should  be  considered  a 
"typical"  or  normal  example;  hova  vet,  it  ®ust  be  clearly 
uniarstood  that  the  example  is  in  no  way  restrictive.  Most 
of  the  system  components  ma  y be  used  in  combination  with 
othar  components  to  build  complex  system  functions.  The 
various  logical  relations  will  become  more  apparent  to  the 
usar  aaalyst  as  he  follows  through  the  detailed  descriptions 
of  the  various  components , 

FS  accepts  th<  user's  description  of  the  data  element:-, 
maxing  up  the  data  file  in  punched  card  form.  Output  from 
the  component  is  th«  F i 1?  Format  Table  (FF?|  which  defines 
the  structure  of  the  file  to  he  tonei.  Since  the  F FT  is  an 
actual  physical  part  of  the  data  base,  file  initiation  is 
p?cfor«3d  by  this  step. 

FI  accepts  the  F?T  as  a part  of  its  input;  together  with 
transaction  data  the  user  desires  to  place  in  his  tile. 
Using  taj  user's  instructions  (logic  statements),  it 
performs  the  actual  update  function  which  results  in  the 
updated  (or  new)  data  file.  Paralleling  this  process, 
various  forms  of  "auxiliary"  output  may  be  produced  under 
usar  control. 

The  retriever  may  then  be  utilized  to  extract 
information  from  the  data  file.  The  result  of  this  step  is 
th>  creation  of  two  data  sets:  one  containing  the  records 
extracted  from  the  data  file,  and  the  other  consisting  of 
the  sort  or  sequence  control  fields  the  user  specified  as 
desired  for  answer  sequencing.  A standard  sort  is  applied 
to  the  sort  fields,  and  the  resultant  file  is  retained  along 
with  the  data  file  created  by  the  retrieval  operation. 
Since  the  sort  field  file  includes  "pointers"  back  to  the 
data  file,  a direct  access  technique  of  recovering  the 
retrieved  data  is  applicable. 

This  composite  of  two  file;,  is  then  passed  to  the  Output 
Pcoc°ssor,  which  by  applying  user-supplied  instructions 
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provides  the  desired  final  report.  Not?  that  the  output 
processor  nay  accept  a data  file  directly,  rather  than  first 
applying  the  retrieval  process.  This  technique  is  useful 
wh»n  ti » sequence  3 f t he  oi*put  in  the  final  report  is  not 
critical  or  when  it  is  the  same  as  th?  original  sequence  of 
th»  lata  file. 

System  formatted  output  may  be  obtained  with  the  Quick 
Inquiry  Processor  (QUIP)  which  can  also  perform  a retrieval 
function.  Using  either  a data  file  or  the  results  of  a 
retrieval  run  as  a data  source,  output  reports  are  quickly 
ini  simply  prepared. 

The  TP  component  utilizes  local  2250,  2250  and  3270 

devices  and  remote  2260,  3270  or  1050  terminals  as 

input/output  units.  Data  files  may  be  queried  and  reports 
formatted  or  the  files  may  be  updated.  Output  data  may  be 
reviewed  ir.  a conversational  mode  at-  the  terminals  or  may  be 
directed  to  printers.  This  processing  will  generally 

parallil  the  processing  by  other  system  components. 

with  this  brief  introduction,  the  rest  of  this  volume 

addresses  the  general  concepts  applicable  to  the  total 

system,  and  generally  provides  those  common  guides  required 
for  use  of  any  component. 
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Section  2 

S YSTE  K CONCEPTS 


NIPS  360  PPS  is  a generalized  f ile  -hand  ling  system. 
Usinj  laaguages  which  have  been  specifically  designed  to 
.support  the  requirements  of  the  users  of  the  various 
components,  the  analyst  can  define  the  capabilities  to 
process  a specific  data  file.  This  section  presents  a brief 
outiina  of  the  concepts  of  a NIPS  360  FFS  data  file,  the 
method  of  handling  data  elements,  and  the  general  system 
language  specifications. 


2,1  General  File  organization 

A data  file  created  by  a user  with  NIPS  360  FPS  is  a 
collection  of  information  pertaining  to  a common  area.  The 
til»  consists  of  records,  each  of  which  contain  data 
describing  the  attributes  of  a single  subject.  For  example, 
the  sample  file  presented  in  section  4 is  a data  file 
containing  information  describing  the  status  and  disposition 
of  all  military  units  in  the  armed  forces.  Each  record  in 
the  file  contains  data  which  completely  defines  a single 
unit.  Thus  the  tile  is  a collection  of  records  with  an 
ocder  determined  by  a unit  identification  code. 

Eacn  record  in  a data  file  has  a common  format.  This 
format  is  defined  by  the  user  and  communicated  to  the  system 
through  the  use  of  the  FS  component.  The  format  of  a file 
rsfars  to  the  format  of  data  records  in  a specified  file. 
Each  location  in  a record,  where  a data  value  is  stored,  is 
called  an  element  of  the  r-u..>rd.  When  the  file  is  being 
designed,  the  user  assigns  a ■ -tonic  name  to  each  element 
in  the  record.  The  collection  of  element  nates,  along  with 
thair  functional  relationship,  constitute  the  format  of  a 
record  and  hence  the  file  itself. 
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'’’he  complete  description  of  a file's  format  is 
maintained  in  the  EFT  which  is  generated  by  the  PS 
coaponant,  During  file,  processing,  the  user  states  his 
problea  using  the  aneaonic  eleaent  names  to  reference  data 
locations  in  a record.  The  systea  translates  these  naaes 
thcough  the  FPT  into  internal  code  allowing  access  to  actual 
racoid  data. 

Examples  of  usage  of  the  various  concepts  covered  in  the 
following  subsections  are  provided  by  Section  <* , Saaple  NIPS 
3 1» D PFS  Data  File. 


2.2  Data  Record  Organization 


2.2.1  Data  Record  Eleaents 

The  locations  in  a record,  where  data  values  ar  e stored, 
have  been  defined  as  eleaents  of  the  record.  An  individual 
?l*«2nt  Ls  called  a field.  This  is  the  tera  used  to 

identify  a portion  of  the  data  record  where  a single  data 

itea,  such  as  an  individual's  naae,  aay  be  stored.  During 
the  file  definition  process,  this  field  is  given  a aneaonic 
naaa  which  is  stored  as  an  entry  in  the  FFT.  When  the  file 
is  processed,  the  us°  of  the  field  naae  in  a language 
stitaaont  permits  *ha  user  to  operate  on  the  data  contained 
in  a specific  location  of  all  records  in  the  file.  All  the 
individual  eleaents  in  the  data  record  are  defined  by  the 
user  as  fields  and  given  unique  names.  This  provides  the 
systaa  with  a coaplete  lap  of  the  data  organization  in  a 
record. 

Occasionally,  several  adjacent  fields  in  a data  record 

hav?  a Logical  relationship,  and  it  would  be  desirable  to 

operate  on  thea  as  a single  itaa  with  one  naae.  In  such  a 
casa,  ona  or  sore  adjacent  fields  nay  be  defined  together  as 
a group  with  a new  naae  suppliad.  An  exaaple  of  this  would 
be  the  case  where  two  fields  have  been  defined  to  contain  an 
individial's  last  and  first  naae,  respectively. 
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"hese  two  fields  could  be  defined  together  as  a group  for 
one-step  data  manipulation. 


2.2.2  Data  Record  Element  Hierarchy 

In  conventional  information  systems,  the  record  is  the 
basic  unit  of  information  containing  a fixed  number  of 
element  values.  The  NIPS  ?60  FFS  permits  the  user  to  define 
a data  record  with  a hierarchical  relationship  among  the 
elements  of  the  record.  At  the  lover  level,  the  record  nay 
contain  a variable  number  of  data  values  for  each  element. 
The  term,  set,  is  introduced  to  define  a collection  of  data 
record  elements  at  the  same  level. 


2 . 2 . 2 . 1 Fi  xed  Set 

The  fixed  set  corresponds  to  the  first  level  in  data 
record  hierarchy.  The  fixed  set  is  a collection  of  elements 
(fields)  which  need  only  one  data  value  to  satisfy 
requirements.  An  example  of  a fixed  set  element  would  be 
tha  field  (element)  of  the  sample  file  in  section  4,  COMDR , 
which  contains  the  Commanding  Officer's  name.  Since  each 
record  of  this  file  contains  the  information  on  a single 
military  unit,  there  will  be  only  one  Commanding  officer. 


2.2.  2.2  Periodic  Set 

In  a data  record  there  may  be  a collection  of  data 
elements  which  nay  assume  more  than  one  set  of  data  values 
witain  the  record  itself.  The  collection  of  data  elements 
is  called  a periodic  3ot.  A periodic  set  is  a collection  of 
data  eLements  which  are  logically  related  and  may  contain 
multiple  data  entries,  all  with  the  same  format. 

A collection  of  data  vi  1U9S  whose  format  is  defined  for 
tha  periodic  set  is  called  a subset.  The  number  of  subsets 
for  a periodic  set  in  a data  record  is  under  the  control  of 
tha  usac.  A point  of  importance  is  that  each  subset  is  s 
collection  of  data  with  t. he  same  format  as  all  other  subsets 
of  the  sane  periodic  set. 
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Since  data  records  identify  a unique  subject,  a unique 
record  identification  must  be  provided.  The  user  must 
lefine  one  or  more  elements  of  the  fixed  set  to  be  used  for 
record  control.  The  data  value  (s)  found  in  this  recocd 
elsmentfs)  must  be  unique  throughout  the  file.  Very  often 
the  data,  and  the  elements  used  for  such  a purpose,  are 
known  as  the  Recocd  Control  Sroup,  Record  ID,  or  Record  Key. 


2.2.  2.5 


Data  Record  Organization  Summary 


This  subsection  uses  figure  1 as  a graphic  example  for 
the  points  covered.  Shown  at  the  top  of  the  figure  is  a 
block  diagram  representing  a data  file  which  may  consist  of 
a variable  number  of  records.  Por  purposes  of  illustration, 
one  of  the  records  in  the  file  is  "broken  out"  to  show  its 
possible  configuration.  The  data  format  in  this  record  is 
the  same  as  that  used  by  ill  records  in  the  file.  However, 
thi  data  contents  of  the  record,  as  well  as  the  number  of 
data  entries,  may  differ  from  record  to  record. 
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Figure  1.  NIPS  360  FFS  Data  Record  Organization 
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This  file  has  four  elements  defined  as  a fired  set. 
These  elements  were  defined  as  fields  during  FS  with  names 
associated  with  each  field.  For  example,  the  names  FI,  F2, 
F3  , and  F4  are  used.  When  the  record  is  created  by  the  PH 
component,  the  uset  can  cause  data  froa  incoming  transaction 
records  to  be  placed  in  the  fixed  set  of  the  record  by  using 
the  field  name  as  reference. 

Th?  file  record  s ho*  n in  figure  1 has  formats  defined 
for  three  periodic  sets.  The  format  and  data  used  in 
Periodic  Set  1 will  be  used  for  illustration.  When  the  user 
defines  the  file  format  (data  record),  three  logically 
related  elements  could  contain  multiple  groups  of  data 
values  within  a single  record.  Therefore,  during  the 
definition  of  the  fields  Pll,  P12,  and  PI  3,  the  user  define’’ 
thit  the  fields  be  treated  functionally  as  Periodic  Set 
This  then  established  the  common  format  which  groups  of  . 
values  would  follow  as  they  are  entered  into  the  re. 

Each  group  of  data  values,  conforming  to  the  format  lot 
Periodic  Set  1,  is  referred  to  as  a subset.  The  number  of 
subsets  contained  in  a record's  periodic  set  is  never 
defined  by  format.  For  Periodic  Set  1,  as  shown  in  figure 
1,  there  exists  five  subsets  of  data.  When  NIPS  360  FFS  is 
processing  file  records,  a single  subset  in  a periodic  set 
is  referenced  at  one  time.  Therefore,  the  use  of  the  field 
name,  P12,  in  a retrieval  statement,  has  sequential  access  to 
five  different  data  values  in  one  record. 

In  the  variable  set  illustrated,  no  format  is 
established  for  any  data  values.  However,  if  a data  file  is 
to  have  records  containing  variable  sets,  this  must  be 
defined  in  the  PS  run  to  establish  internal  pointers  in  the 
record.  Any  data  that  is  placed  in  the  variable  set  for  a 
record  is  maintained  by  internal  painters  describing  to  the 
system,  the  actual  location,  and  volume  of  information. 

The  sizes  of  data  records  in  a NIPS  360  FFS  data  file 
may  vary.  If  a file  consists  only  of  a fixed  set,  then  all 
records  in  the  file  are  of  constant  length.  However,  a data 
file  defined  with  one  or  more  periodic  sets  for  its  records 
will  most  likely  hav*  record  lengths  that  vary  considerably. 
This  occurs  since  the  periodic  sets  of  some  records  will 
contain  lore  subsets  of  data  than  others. 
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The  maximum  size  of  a data  record  is  also  a variable. 
For  the  Output  Processor,  File  Maintenance,  and  Quick 

nquiry  processor  components,  the  system  allocates  space 

iLLed  a "processing  block"  to  contain  the  part  of  the  data 
record  processed  during  the  run.  The  core  allocation  size 
for  the  processing  block  is  variable;  the  size  allocated  is 
determined  by  the  specific  component.  The  default  size 
allocated  by  PM  is  16,000  bytes,  and  the  default  size 

allocated  by  QUIP  is  10,000  bytes.  The  analyst  is  thus 
assured  the  capability  of  processing  complete  records  of  a 
size  up  to  10,000  bytes  in  QUIP,  and  up  to  16,000  bytes  in 
Pais  constraint  is  a "worst  case"  condition,  since  the 
system  only  loads  that  portion  of  the  file  .ecord  that  is 

being  processed  during  the  job,  causing  the  record  to  be 

loaded.  Loading  is  performed  on  a set  basis,  so  that  a job 
requiring  examination  of  lata  from  Periodic  Sets  1 and  2 of 
a file  requires  the  system  to  load  the  fixed  set.  Periodic 
Set  1 , and  Periodic  Set  2. 

Effectively  then,  the  analyst  may  choose  to  constr  a 
ais  fila  record  size  to  10,000  bytes  and  avoid  any  further 
considerations  of  processing  regui  *enen  ts  related  to  core 
siza.  Whan  using  FM,  the  analyst  can  determine  the  size  of 
the  processing  block  by  putting 

P A R M = ' PB  SI  ZE  =n  K' 

(woare  n can  range  from  1 to  99)  on  the  FM  EXEC  card. 
Similarly,  when  using  QUIP  in  the  batch  mode,  the  analyst 
can  enter  P AR  H ='  PB  SIZE  =nK*  on  the  QUIP  EXEC  card;  (however, 
bacausa  of  design  constraints,  the  U IP  processing  block 
cannot  exceed  99K ) . For  source  dire;  t QUIP  runs  against 
ISAM  files  (this  includes  on-line  QUIP),  the  system  will 
compute  the  size  of  the  processing  block  required  (up  to 
3K|  and  allocate  that  size.  If  a file  design  logically 
requires  larger  record  sizes,  the  analyst  nay  still  process 
that  file  just  as  long  as  the  combination  of  sets  he  desires 
to  process  in  a single  job  can  be  contained  within  the 
processing  block  allocation  of  the  system. 
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2.  3 Data  Value  Modes 

Tha  user  of  NIPS  360  has  the  option  of  selecting 
different  nodes  by  which  data  will  be  stored  in  the  record 
elements  of  the  data  file.  During  FS,  each  element.  in  the 
record's  fornat  is  defined  to  hold  its  data  value  in  a 
specific  mode.  This  node  selection  specifies  the  internal 
method  by  which  data  is  stored.  It  is  necessary  for 
employing  and  limiting  certain  types  of  operations  against 
data  during  file  processing. 


2.3.1  N umeric  Mode 

pecord  elements  (fields  and  groups)  containing  numeric 
values,  which  wilL  be  processed  using  mathematical  operators 
summations),  should  be  defined  as  numeric  mode. 
Field  elements  defined  as  numeric  are  limited  to  a maximum 
of  10  integers  within  the  range  of  ♦2  ,147  ,483,647.  Although 
correct  processing  can  be  performed,  numeric  fie’ds  should 
generally  not  be  defined  within  a group  since  system 
efficiency  will  be  impaired.  Normally,  all  fields  defined 
as  numaric,  regardless  of  size,  are  stored  in  the  data 
record  as  binary  words.  This  mode  permits  fixed  point 
binary  arithmetic  to  be  used  by  the  system  and  allows  full 
use  of  the  more  efficient  binary  set  of  machine 

instructions.  When  a numeric  field  is  defined  in  a group, 
tha  valua  contained  in  the  field  is  represented  as  zoned 
EBCDIC  bytes.  Pequired  data  conversions  are  made  by  the 
system  without  user  intervention.  Note  that  a numeric  field 
defined  within  a group  is  initialized  to  EBCDIC  blanks.  It 
is  the  user/analyst  responsibility  to  initialize  these 
fields  to  EBCDIC  zeros  during  F(!  processing.  Failure  to 
initialize  these  fields  will  result  in  data  exception  errors 
whan  using  these  fields  with  arithmetic  operators  and  data 
value  editing  during  output  processing. 

Any  field  or  group  defined  as  numeric  mode  will  allow 
output  editing  to  be  defined  by  the  user.  This  function 
permits  leadinq  zero  suppression,  decimal  point  insertion, 
and  so  forth.  Subsection  2.5  discusses  the  use  of  the  Edit 
function  in  NIPS  360  FPS. 
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Th»  nuiecic  mode  specifies  that  data  values  are  to  be 
r ight- justified  for  a record  element.  This  leans  that  if  a 
nunri:  value  is  shorter  than  the  defined  eleaent,  the  value 
will  be  right- justified  with  zero  padding  on  the  left  to 
fill  in  the  rest  of  the  allocated  space.  If  the  numeric 
value  is  longer  than  the  defined  element,  truncation  will 
taka  pLace  on  the  left  when  the  data  is  stored. 


2.3.2  Alphameric  Mode 

Record  elements  (field  and  groups)  which  are  defined  as 
alphameric  mode,  permit  all  characters  of  the  EBCDIC  set  to 
be  stored  as  bytes.  All  logical  operations  can  be  performed 
on  data  stored  in  this  mode.  However,  the  data  may  not  be 
us»1  as  values  in  mathematical  processing  (e.g.,  addition, 
subtraction,  etc.),  nor  may  the  data  be  edited  with  a user- 
defined  mask  during  OP. 

Record  elements  defined  as  alphameric  mode  imply  that 
data  stored  in  them  is  left- justified . For  example,  if  a 
data  value  is  shorter  than  the  field  or  group  where  it  is  to 
be  stored,  the  value  will  appear  lef  t- justi  fied  in  the 
location  with  trailing  blanks.  If  the  data  value  is  longer 
than  the  field  or  group  in  the  record,  it  will  be  stored 
with  truncation  occurring  on  the  right. 

The  system  assumes  the  alphameric  mode  for  all  variable 
sets  in  the  data  file. 


2.3.3  Geographic  coordinate  Mode 

A special  ite*  mode  designator,  coordinate,  is  used  for 
cases  where  geographic  coordinates  are  to  be  stored  in  the 
data  record  for  retrievals  using  the  geographic  retrieval 
opacators.  Circle  Search,  and  Polygon  Overlap,  This  mode 
may  be  used  for  both  field  and  group  definitions,  depending 
upon  the  manner  in  which  the  coordinate  values  are  stored. 
Each  term  in  a coordinate  pair  defines  a point  which  will  be 
storad  as  a binary  word  in  t hp  data  record,  a standard 
system  subroutine  will  oe  used  a utomati  ily  to  translate 
tha  coordinate  values  to  and  from  l binary  word  format  when 
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the  standard  external  foraat  is  followed.  The  user  aay 
define  the  coordinate  point  containing  both  latitude  and 
longitude  as  a single  field  and  the  s ystea  will 
a utoaati  call  y generate  two  binary  words  to  hold  the  values 
after  conversion.  He  may  also  define  the  latitude  value  and 
lonjituda  values  as  individual  fields  and  then  define  thee 
together  as  a coordinate  group.  The  stand**--!  err. * ' 

fociat  is  shown  below: 

Latitude  Longitude 

A AH  MX  (5  bytes)  BBBHHY  (6  bytes) 

AAMMSSX  (7  bytes)  BBBMNSSY  (8  bytes) 

w here 

A = Lat  .tude  in  degrees 

B = Loigitide  in  degrees 

M = H .nutes 

S = S econds 

X&Y  = Appropriate  hemispheres. 


If  a user  wished  to  define  a coordinate  value  in  his 
record  with  the  latitude  and  longitude  as  individual  fields 
with  precision  only  to  minutes,  he  would  define  two 
coordinate  fields  with  lengths  of  five  and  six  bytes, 
re  specti  vel  y.  Then  the  two  fields  would  be  defined  as  a 
coordinate  group. 

If  the  user  wished  to  define  a single  field  containing 
a coordinate  point  with  precision  to  seconds,  he  would 
define  a coordinate  node  field  with  a size  of  15  bytes. 

The  coordinate  mode  may  be  used  for  a group  containing 
several  fields  and/or  groups  of  coordinate  data.  This 
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p^rn  ts  the  use  of  a single  name  defining  a line  or  area  to 
be  use!  with  the  polygon  overlap  search  operator  in  the  NIPS 
components.  Such  groups,  however,  are  not  subject  to 
automatic  input  or  output  conversion  by  the  system.  Only 
field/groups  whose  external  length  is  5,6,7,9,11,  or  15  will 
be  automatically  converted. 


2.4  Data  Value  Conversion 

The  user  has  the  capability  of  defining  routines  which 
may  be  used  to  perform  data  value  conversion  as  data  is 
placed  into  or  taken  from  a record.  Data  may  also  be 
validated  either  as  a transaction  item  or  as  it  resides  in 
a record  using  this  technique. 

Thj  conversion  routines  nay  be  developed  in  two  ways. 
In  one  method,  the  user  actually  writes  a subroutine  using 
one  of  the  OS/360  programming  languages  to  perform  the 
iasiLel  conversion  process.  The  subroutine  is  written  to 
accept,  through  a calling  sequence,  the  data  item  to  be 
converted.  It  returns  the  converted  data  value  to  the 
calling  sequence  when  finished.  The  other  method  available 
to  the  user  is  to  develop  a table  consisting  of  a collection 
of  argument-function  pairs  of  data.  The  argument,  being  the 
data  to  be  converted  and  the  function  being  the  converted 
dati  value,  is  supplied  as  a group  on  each  source  card. 
Both  methods  have  an  appropriate  cataloged  procedure  which 
is  used  to  develop  the  actual  executable  load  nodules  using 
source  statements  as  input.  These  resulting  load  modules 
irs  placed  on  a predesignated  library  for  use  by  all 
components  of  the  system.  When  the  subroutines/tables  ace 
developed  by  the  user  for  an  application,  they  are  defined 
for  use  in  either  input  conversion  or  output  conversion.  In 
addition,  they  ace  defined  to  accept  data  and  supply  data 
with  specific  lengths  and  modes.  An  input  conversion 
subroutine/table  is  used  to  accept  data  input  from  either  a 
system  work  area,  a transaction  record  during  update 
processing,  or  a query  statement  and  produce  a result 
compatible  for  direct  placenent  in  a data  record  field  or 
group.  An  output  conversion  subroutine/table  is  used  during 
output  processing  to  accept  a data  value  from  either  a data 
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record  ?Ister»t  or  s y;tea  work  it  *-a  to  supply  the  converted 
result  for  output. 

The  use  of  conversion  subroutines/tables  may  be  either 
automatic  or  under  control  of  the  us  r tarough  the  language 
statements  defining  the  particular  run.  The  following 
conents  describe  * he  methods  by  which  t n o conversion 
routines  are  called  into  action. 

During  FS  each  field  and  group  in  the  record  may  be 
flagged  with  the  nate  of  an  input  and/or  output 
subroutine/table.  This  definition,  at  FS  time,  will  cause 
thi  automatic  use  of  the  conversion  routines  whenever  the 
field  or  group  names  so  flagged  are  mentioned  in  the 
laajuag?  statements  of  the  PASP,  OP,  and  3UIP  components. 
The  user  may  negate  their  automatic  use  in  a run  by 
associating  a special  term  with  the  field  or  qroup  name  when 
mentioned  in  a statement.  Conversely,  the  user  may  override 
tha  specified  conversion  subroutine/table  and  substitute 
another  one  by  providing  the  new  subroutine/table  name  with 
the  field/qroup  name  in  a statement. 

A 1L  component  of  the  system  which  perform  file 
processing  allow  the  user  the  capability  to  dynamically 
state  in  his  language  statements  the  use  of  a conversion 
subroutine/table  for  a particular  field  or  group.  Thus 
conversion  may  be  effected  for  special  applications  with  a 
data  file.  This  technique  also  permits  subroutines/tables 
to  be  used  for  data  validation  or  direct  conversion  in  a 
lata  racord  using  the  Ffl  component. 


2.5  Data  Value  F.diting 

Numeric  mode  elements  in  a data  record  may  be  edited 
during  output  processing.  This  option  permits  the  user  to 
suppress  leading  jecos,  insert  decimal  points,  and  perform 
other  editing  functions.  to  define  the  editing  function 
performed  on  a record  element,  the  user  constructs  an  edit 
mask  containmq  control  characters.  .Special  characters  in 
the  mask  indicate  to  the  system  the  nature  of  the  editing 
operation. 


17 


INTRODOCriON  TO  FILE  CONCEPT? 


The  user  aay  define  the  editing  function  to  the  system 
in  two  different  h ys.  The  first  method  is  to  define  an 
adit  Basic  for  a record  element  when  the  file  is  structured 
using  the  FS  cotponent.  The  PFT  entry  for  this  element  will 
tn>a  always  carry  the  edit  task  for  use  by  the  op 
components.  If  the  edit  waste  is  defined  in  this  manner, 
OUIP  and  OP  will  automatically  use  it  whenever  the  record 
element  is  referenced  for  output  display. 

The  second  way  the  user  aay  define  an  edit  operation  is 
to  actually  include  an  edit  aask  as  a literal  associated 
with  an  element  in  the  language  statement  for  a particular 
application.  The  procedure  used  to  write  an  edit  aask  is 
defined  in  subsection  3.4  of  this  manual. 

so  far  in  the  discussion  of  edit  masks,  it  has  been 
assume!  that  the  data  value  to  be  edited  has  coae  from  a 
numeric  mode  record  element.  Howevpr  the  user  aay  employ  a 
lifferant  approach  to  data  value  editing  as  follows.  Data 
from  a record  element  may  be  processed  by  an  output 
conversion  subroutine/table  and  the  result  edited  by  a user 
defined  aask.  Cate  must  be  taken  to  ensure  that  the  output 
from  the  conversion  subroutine  is  nuaeric  so  that  it  is 
acceptable  to  the  edit  prcEPSS. 


2.6  General  Language  Specifications 

Each  system  component  has  its  own  language  which  is  used 
by  the  analyst  to  define  the  file  processing  functions  for 
a computer  run.  Despite  the  number  of  different  languages, 
they  aay  be  easily  learned  by  the  analyst  since  they  ate 
basically  similar  and  differ  only  in  their  application  to  a 
problem.  This  section  of  the  manual  is  concerned  only  with 
introducing  the  terminology  of  the  lar.  juages.  Each  volume 
of  this  manual  will  define  the  characteristics  and  use  of 
thj  associated  language  foe  that  component. 


2.6.1  Defini  tion  s 

The  following  list  d°fines  some  elementary  language 

terns. 
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Word  - A contiguous  string  of  characters, 

qenerally  considered  to  he  composed  of 
the  alphameric  set  and  explicitly 
restricted  to  exclude  the  special 
characters  blank,  com , period,  single 
quote,  "at"  symbol,  and  ampersand. 

Term  - Generally  used  synonymously  with  word. 

Clause  - A string  of  words  separated  by  commas 

and/or  blanks.  The  period  is  explicitly 
excluded  from  the  body  of  a clause. 

Statement  - Hay  contain  one  or  more  clauses  and  is 

always  terminated  by  a period. 

Operator  - A systea  reserved  word  explicitly 

directing  an  action.  For  example,  LIST, 
EQUALS,  GREATER,  THAN,  SUN , etc,,  are  all 
considered  operators. 

Connectors  - Generally  restricted  to  the  Boolean 

connectors  AHD  and  OR. 

Condition  - A special  case  of  the  general  category  of 

Statement  statement,  this  form  implies  that  the 

user  is  requesting  the  system  to  test  for 
a specified  condition.  Implies  the 
existence  of  an  action  directive 
statement,  either  explicitly  or 
implicitly  stated. 

Action  - A special  case  of  the  general  category  of 

Stateient  Statement,  this  form  is  a user  request 

for  a specific  system  action,  and  may  or 
may  not  be  preceded  by  a Condition 
St  at  ement . 


2,6.2  Language  Format 

Several  formats  are  commonly  used  in  systems  work.  They 
ars  often  identified  by  names  such  as  free-foroat,  comma- 
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toriat,  aad  fixed- for  mat . The  preferrad  fora  generally  used 
in  this  system  is  known  as  free-format.  This  tcraat  by 
definition  offers  the  following  characteristics: 

a.  words  Bay  be  separated  hy  either  coaaas  or  blanks 

or  both  in  any  combination,  and  in  any  number. 

b.  Stateaents  and/or  clauses  aay  run  serially  froa 

card  to  card,  or  aore  generally,  froa  input  record 
to  input  record.  Words  aay  not  be  split  between 
records  or  cards. 

c.  Statements  aay  be  initiated  in  any  charactei 

position  of  the  input  record,  and  aay  terminate  in 
any  position. 

d.  Other  than  cases  in  which  the  sequence  of  the  input 

stateaents  are  related  to  the  sequence  of  functions 

requited  by  the  system,  no  sequencing  requirements 
are  arbitrarily  imposed. 

Carl  columns  1 - 71  generally  contain  language  statements. 
Sou  coiponents  offer  the  capability  of  providing  a card 
sequence  check  if  the  user  provided  a sequence  number  of  all 
carls  in  his  source  deck  in  locations  73  through  80. 

Soae  of  the  components  require  a parameter  string  with 
optional  values  in  the  string.  Since  interrogation  of  the 
string  is  based  on  a positional  relation  and  identification 
of  the  field  information  is  not  feasible  without  this 
relation,  omitted  fields  must  be  clearly  indicated  to  the 
system.  When  this  condition  occurs,  the  basic  punctuation 
rule  is  changed: 

Note:  words  may  be  separated  by  one  or  more  blanks, 

or  not.  aor?  than  one  comma,  with  or  without 
multiple  blanks.  The  notation  "double  comma" 
indicates  to  the  system  that  a field  has  been 
omitted  . 

Tha  PN  component  uses  a language  which  deviates  somewhat 
from  tha  conventions  outlined  above.  Because  of  the  power 
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ani  flexibility  offered  by  the  component,  the  language 
raseibLis  that  of  a computer's  assembly  language. 

2.6,1  NIPS  360  FFS  Langaage  Contents 

The  words  or  terms  use!  by  the  analyst  to  describe  a 
tile  processing  function  must  conform  to  the  language 
specification  for  the  appropriate  system  component. 
However,  all  component  languages  may  have  an  analogy 
relating  them  to  our  own  spoken  language.  For  example,  in 
writing  a statement  to  direct  a processing  function,  the 
words  used  are  similar  to  the  subject,  verb,  object,  and 
conjunctions  in  an  English  sentence.  In  all  of  the  system 
component  languages,  there  are  two  basic  types  of  words. 
First  are  the  system  reserved  words  which  are  recognired  as 
indicating  specific  operations.  The  combination  of  these 
words  in  a statement  define  the  logic  to  be  used  by  the 
system  component.  In  an  analogy  to  the  English  sentence, 
thasa  words  would  be  considered  the  verb  indicating  the 
action  to  be  performed  and/or  the  conjunctives  indicating 
th9  logical  relationship  of  words. 

The  second  major  type  of  words  in  the  NIPS  360  FPS 
languages  are  those  supplied  by  the  use...  These  words  could 
be  considered  analogous  to  the  subject  and/or  object  of  an 
English  sentence  indiciting  what  is  involved  in  the 
processing  function  and  the  result  obtained.  The  words 
supplied  by  the  user  are  of  several  classes  and  are 
discussed  below: 

a.  Names  — Names  are  used  by  the  analyst  to  reference 
a file,  subfile,  record  element  or  field  conversion 
subroutines,  conversion  tables,  and  edit  masks. 
All  names  are  formed  under  the  following  rule: 

o A name  may  be  from  one  to  seven  characters 
with  no  embedded  blanks  or  special  characters. 
The  DSNAHE  parameter  of  the  Data  Definition 
(DD)  card  which  corresponds  to  the  7-character 
file  name  may  be  a qualified  data  set  name  up 
to  44  characters  in  length.  The  file  name 
must  be  the  last  segment  of  the  qualified 
name.  The  first  character  must  be  alphabetic. 
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All  remaining  characters  *ay  be  alphabetic  or 
n ui er  ic. 

o Names  for  data  files,  libraries  and  index  data 
sets  aust  not  end  with  the  characters  X,  L,  or 
S.  Various  NIPS  coaponents  append  these 
characters  to  the  end  of  the  data  set  naae  for 
identification.  Their  use  as  the  last  user 
supplies  character  can  produce  unpredictable 
results . 

o Naaes  for  RASP  titles,  subroutines  and  tables 
aust  not  end  with  the  character  zero.  Zeroes 
are  appended  when  organizing  their  object 
aodules  for  storage  on  the  file  library. 
Their  use  as  the  last  user  supplied  character 
will  result  in  errors  and/or  unpredictable 
c esults . 

b.  £sUrJ£jiBina_l2If§_iMJaiJ££al§  “ The  user  quite 
often  aust  supply  a data  walue  to  a systems 
component  directly  through  the  language  statenent. 
Two  different  options  are  available  for  this 
approach,  and  such  words  are  called  self -def ining 
teras  aa  d literals. 

o A self-defining  farm  is  a word  aade  up  of  a 

string  of  characters  with  no  es  bedded  blanks 
which  is  interpreted  by  the  system  as  a data 
value.  The  word  is  recognized  as  a self- 

defining ter«  due  to  its  syntactical  position 
with  respect  to  ether  words  in  a statement. 
The  following  self- defini ng  terms  are  treated 
as  data  values  by  the  systea: 

45« 

Tan  k 

o A literal  is  similar  in  concept  to  a self- 

defining tera  except  that  it  is  enclosed 
within  delineator  characters  to  define  its 
width.  The  delineator  used  is  the  single 

quote  sign  (although  some  coaponents  allow  the 


i 
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alternate  iisp  of  an  "at"  sign).  The  purpose 
of  the  delineator  is  to  allow  the  definition 
of  data  values  containing  blank  and/or  special 
characters.  Examples  of  literals  are: 

•Heavy  Tank  • 

» F-105' 

c.  S vstea  Work  Areas  --  Host  coaponents  of  NIPS  360 

P PS  have  interaediate  work  areas  which  are  used  by 
the  analyst  to  store  data  values.  These  work  areas 
are  defined  in  several  ways  according  to  the 
component  concerned.  Although  they  are  reserved 
words  capable  of  recognition  by  the  component  being 
used,  they  are  used  like  naaes.  This  is  because 

they  function  as  the  subject  or  object  of  a 
sentence;  i.e.,  they  do  not  connote  any  action  to 
be  taken,  but  aerely  are  used  to  represent  where 
data  aay  be  found  or  stored. 

d.  Piqurative  Constants  --  Soae  coaponents  of  NIPS  360 

FPS  perait  the  user  of  figurative  constants  to 
represent  data  values.  These  are  reserved 

words  which  stand  for  specific  data  values  and  aay 
be  used  in  place  of  literals  or  self-def ining  teras 
if  appropriate.  Pigurative  constant  words  aay 

be  such  as : 

l ERO 
BLANK 

As  an  exaapie  of  a NIPS  360  FFS  language,  the  following 
P ASP  coaponent  language  sta  tenant  is  illustrated.  This  is 
a conditional  stateaent  causing  search  of  a data  file  for 
qualifying  records  to  be  retrieved.  The  retrieval  criterion 
is  indicated  by  user-supplied  data  values  in  the  stateaent 
i tss l f . 

IE  AREA  E£5iAi  'SOUTH  VIETNAM'  AND  SERVICE  EC  UAL  ARHY. 

Th»  ualeclined  words  are  reserved  words  recognized  by  the 
systea  to  cause  specific  actions  to  occur.  The  reaaining 
words  are  user  supplied  and  defined  words  indicating  the 
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specific  qualification  for  action.  Due  to  the  syntax  of  the 
lingua]*,  the  system  will  interpret  the  words  AREA  and 
SERVICE  as  data  record  element  names.  The  word  SOUTH 
VIETNAM  Is  a literal  used  to  introduce  a data  value  to  the 
system  through  the  source  language.  Likewise,  the  word  ARMY 
is  a sslf-defining  term  used  to  supply  a data  value. 

The  special  characters  such  as  comma,  blank,  and  period 
are  used  by  the  different  component  languages  for  special 
usage  and  have  special  significance  to  th?  system.  The 
mathematical  operators,  plus,  sinus,  and  equal  symbols, 
portray  their  normal  math  function  in  some  uses. 
Multiplication  will  be  represented  by  the  asterisk  and 
division  by  a slash.  Parentheses  are  used  to  logically 
group  clauses.  In  addition  to  these  direct  and  straight- 
forward rules,  the  following  sppcial  characters  are  used  foe 
th?  indicated  purposes, 

# (poual  or  number  symbol) 

(8-3)  punch) 


/ (Slash) 

((X-l  punch) 


$ (Dollar  Sign) 

(11-3-8  punch) 

' (SingLa  Quote) 

( S-  8 punch  ) 


s (Ampersand) 

(12  punch) 


Used  to  delineate  subroutine 
names  in  the  input  source 
language  (other  than  ?S)  . Used 
in  double  form,  negates  an  FFT 
specification  for  a subroutine. 

Used  to  separate  numeric  digits 
when  indicating  partial  field 
notation. 

Used  as  an  "universal”  match 
character  in  comparison  literals. 

Used  to  delineate  literals. 

Used  in  double  form,  negates 
an  FFT  specification  for  a edit 
na  sk , 


Used  to  identify  a field  name  used 
as  an  operand  of  a conditional 
expression  in  place  of  a literal 
or  self-defining  term. 
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«DI  (descending  sort  flag)  Used  to  identify  a field  to  be 

sorted  in  a descending  Banner 
in  either  QUIP  or  P AS  P. 

Optional  use  of  selected  special  characters  which  perait 
compatibility  with  14  10  PPS  source  statements  is  discussed 
whare  applicable  in  each  cosponent  volume  of  this  aanaal. 
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2.0.4  nips  360  FFS  Reserved  Words 

This  subsection  contains  a list  of  reserved  words  which 
are  interpreted  by  the  systea,  They  aay  not  be  used  as 
mass  in  any  language  statements, 

RES£RVED_N0££S 


A 

CLASS 

PINAL 

ABSEN  T 

CLASSIF 

PI  ND 

ADD 

COMPUTE 

POR 

AFTER 

CONTAINS 

FROM 

ALL 

COORD 

FURTHER 

ALP  HA 

•COUNT  (N) 

GE 

AND 

CREAT  E 

GO 

ANY 

D 

GOTO 

APE 

DECIMAL 

GS  EATER 

AT 

DELETE 

GROUP 

AVERAGE 

DDISK 

GROUP  I D 

BEFORE 

DISPLAY 

GT 

be-^heen 

DIV 

GTE 

BINARY 

EARLIER 

•HEADER(N) 

BLANK 

EDIT 

HTOTAL 

BLANKS 

EJPCT 

IP 

BT 

EQ 

IN 

C A9  D ( XI 

EQUAL 

INCLUDES 

CH 

EQUALS 

IN  ITIAL 

CHAN  GES 

EXECUTE 

IS 

CIR 

EXTRACT 

♦LABEL  (X) 

CIRCL  E 

PIELD 

LATER 

FIELDS 

LP 
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LIMIT 

OR 

SUB 

*L  IN  E (Xl 

0 V0RLA  P 

SUBFILE 

LIST 

OVP 

SU  BP  T 

LOAD 

PA3END 

♦SUM  (N) 

LT 

PARAH 

SYSDATB 

LTE 

FES 

TAB 

MARK 

PERCENT 

TABL  E 

MAXIMUM 

PRINT 

♦TAB  (X) 

MINIMUM 

pscr 

TEST 

M UL 

punch 

THAN 

NE 

QUERY 

THAT 

N 52 

♦ RECORD  (X) 

THE 

NLE 

RECORDS 

THEN 

NLIN  es 

REPLACE 

TITLE 

NLT 

S ELECT 

TO 

N LTE 

SET 

TRAILER 

NO 

SIGNOPF 

VSCTL 

N3G0 

SIGNON 

HI  THIN 

NOT 

SPACE 

♦WORK  [M 

NOTE 

START 

ZERO 

NUMEP 

STOP 

ZEROS 

DP 

OPDATE 

•Not«> 


1.  ( N i stands  for  either  i b Is  nk  or  the  nuabers  z through 
nine. 

2.  (M ) stands  for  either  s blank  or  the  nuabers  one  through 
nine. 


3.  (X)  represents  the  digits  1-999  and  also  digits  followed 
by  a letter,  e.g.,  LINE10A 

4.  The  fallowing  naae  prefixes  are  not  allowed:  PSSQ,  VSET, 
7SZ. 

The  naae  0 should  not  be  given  to  a subroutine  or  table 
because  this  is  used  to  specify  descending  sort  in  QUIP  and 
HASP  . 
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SECTION  3 

SYSTEM  tr  SE 


3.1  Cataloged  Procedures 

whan  the  anaLyst  prepares  a job  using  one  of  the  system 
coiponeats,  two  basic  types  of  inforaation  are  supplied  to 
the  system  to  define  its  function.  The  first  se*  of 
information  consists  of  joo  control  statements  written  using 
the  OS/360  Job  Control  Language  (JCL)  . These  statements  are 
interpreted  by  the  S/360  to  define  the  characteristics  of 
the  job  such  as  input/output  devices  required  and  the 
name (s)  of  the  program(s)  to  be  run.  Refer  to  the  IBM  SRL 
publication,  IBM  System/360  Operating  System-Job  Control 
Language  (Form  C28-6539),  for  a description  of  JCL.  The 
second  set  of  information  supplied  consists  of  source 
statemants  written  in  the  language  of  the  required  NIPS  360 
PFS  component  which  define  tha  specific  file  processing 
techniques. 

To  ease  the  requirement  on  the  user  that  he  supply  all 
the  necessary  job  control  statements  whenever  a system 
component  is  used,  cataloged  procedures  have  been  prepared. 
Thase  procedures  ace  sets  of  previously  written  job  control 
statements  which  have  been  stored  in  a System  Library.  Each 
procedure  is  given  a name  which  is  used  by  the  analyst  for 
a particular  job.  The  use  of  such  a name  in  a JCL  Execute 
st?tem»jt  causes  the  system  to  automatically  retrieve  the 
information  necessary  to  define  a job  to  the  computer.  In 
ths  simplest  case,  a job  using  the  cataloged  procedures  for 
the  FS  component  would  appear  as  follows: 

1.  //JOBYYZ  JCB  (Standard  Parameters) 

2.  //  EXEC  X FS,  IS  AH-TE5TEP,LI3s:TESTER 

3.  //PS.SYSIN  DD  * 

4.  (FS  language  source  statements) 

5 . /* 
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Card  1 --  Is  required  for  each  job  submitted  and  iust  be 
first  in  the  input  deck.  It  is  known  as  the  JOB  statement 
and  is  used  to  give  the  job  a name  such  as  J3BXXZ. 

Card  2 --  Defines  t.  ha  cataloged  procedure  used  for  the 

job.  The  name  XP  S defines  a set  of  job  control  statements 
in  th»  library  necessary  to  support  the  execution  of  the 
File  Structuring  Component.  The  remaining  parameters 
idantify  the  name  and  type  of  file  to  be  structured  and  the 
name  of  the  File  Library. 

Card  3 --  Defines  the  location  where  the  source  input 
language  statements  may  be  found.  In  this  case,  the 
asterisk  is  a parameter  which  indicates  to  the  system  that 
tha  source  input  imediately  follows. 

Card  4 — Is  the  source  language  statement  (s)  written  by 
the  user  to  define  the  specific  functions  desired  from  the 
component. 

Card  5 — Is  a special  JCL  statement  indicating  the  end 
of  the  source  statement  deck. 

Th»  parameters  entered  on  the  execute  statement  (Card  2) 
are  known  as  symbolic  parameters.  Their  function  is  to 
dynamically  alter  the  pre  stored  procedures  at  execution 
time.  The  values  entered  in  this  manner  replace  those  that 
were  defined  when  the  cataloged  procedure  was  placed  in  the 
Procedure  Library. 

3.2  Development  of  Conversion  Tables 

when  the  user  has  the  occasion  which  warrants  the 
conversion  of  data  values  from  one  fora  to  another  and  the 
problem  lends  itself  to  tabular  conversion,  the  cataloged 
procedura  XTABGEN  may  be  used  to  easily  generate  such  a 
table.  The  input  to  the  procedure  XTABGEN  consists  of  cards 
each  of  which  contain  an  argument-function  pair  of  data 
values.  The  argument  is  the  data  value  which  is  to  be 
converted  and  the  function  is  the  data  value  resulting  from 
conversion.  The  procedure  will  accept  these  source  cards 
supplied  by  the  user  and  build  the  table  into  an  executable 
load  module  capable  of  linkage  with  any  NIPS  360  FFS 
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roaponsat.  The  laad  aodule  table  nay  be  stored  in  a library 
alonq  with  other  tables,  subroutines,  retrievals,  and  PITs 
(Report  Instruction  Table  used  by  the  OP  coaponent  to  direct 
output  processing)  . The  na  ae  supplied  by  the  user  for  the 
:onv?rsiDn  table  lust  confora  to  systea  standards  and  be 
unique  in  the  library  in  which  it  is  stored.  The  table  aay 
oe  called  by  naae  for  use  with  any  file  when  it  is 
appropriate. 

Intonation  and  exaaples  on  the  Banner  in  which  the 
procedure  XTABGEN  is  used  aay  be  found  in  the  Utility 
Support  Prograas  voluae  of  the  HIPS  360  EPS  User's  Manual. 


3.3  Developieat  of  Conversion  Subroutines 

When  conversion  for  record  element  data  is  desired,  but 
does  not  lend  itself  to  a tabular  approach,  the  user  may 
wisi  to  write  a subroutine  to  perform  the  conversion.  The 
subroutine  may  be  written  using  any  of  the  D S/ 360- supported 
problea  processing  languages.  The  subroutine  is  compiled, 
link  edited,  and  tested  by  t he  user  before  inclusion  in  the 
systea.  A cataloged  procedure  XSOflLDR  is  available  to  the 
user  for  loading  the  subroutine  (in  load  aodule  fora)  into 
a library  with  Nips  360  EPS  compatible  linkage  established. 
Use  of  this  cataloged  procedure  requires  the  user  to  have 
the  tested  subroutine  as  an  independent  load  aodule  on  any 
library.  Its  location  is  defined  to  the  cataloged  procedure 
KSUBLDR  through  a JCL  statement.  Description  on  the  use  of 
XSUBLDB  is  found  in  the  Utility  Support  Prograas  volume  of 
tha  NIPS  360  FFS  Users  Manual. 

when  writing  the  conversion  subroutines,  certain 
contentions  must  be  followed.  The  remainder  of  this  section 
describes  such  conventions. 

The  user-written  subroutine  should  be  written  as  a 
single  root  segaent  that  is  reusable,  and  the  calling 
seguence  for  the  subroutine  froa  a systea  component  should 
follow  standard  OS/360  linkage  conventions.  Three 
parameters  are  provided  to  the  user  routine.  Paraaeter  one 
is  the  entry  point  to  the  systea  subroutine  loader. 
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Parameter  two  points  to  the  area  P2  described  below  and 
Parameter  three  is  a cell  for  return  code  storage. 


r2 

DC  H • N * 

N = number  of 

arg 

umen  t 

bytes  including 

t railing 

blan 

ks  or 

leading  zeros 

cc 

CLN 

argument  byte 

s 

DS 

:lh 

H = f u nc  ti  on 

leng 

th 

The 

argument  and 

function  may 

be 

either 

alphameric. 

binary  full  word,  coordinate  data  or  EBCDIC  decimal  (a 
particular  subroutine  is  designed  for  a specific  type  of 
argument  and  function  combination ) . No  boundary  alignment 
of  argument  and  function  areas  can  be  assumed.  The  output 
function  area  should  be  filled  with  leading  zeros  for 
decimal  data  and  trailing  blanks  for  alphameric  data. 
Decimal  data  will  have  *F  ' and  »D*  sign  zone  bits. 

The  function  output  area  immediately  follows  the 
argument  bytes.  The  high-order  position  of  this  area  is  P2 
♦ N ♦ 2.  Conversion  routines  oust  be  written  to  accept 
variable  length  alpha,  decimal  or  coordinate  arguments.  The 
output  function  size  is  fixed  for  a given  routine  and  should 
always  be  completely  filled.  The  combined  lengths  of  the 
argument  and  function  may  not  exceed  256  bytes. 

Upon  return  from  the  user  routine,  either  register  15 
can  contain  one  of  the  following  return  characters  or  the 
oeLL  lesignated  by  parameter  three  can  be  filled 
according  iy: 

S = Successful 


fl  «=  to  Hatch,  unsuccessful 


The  subroutine 
routines  so  that 
otm  routines, 
performed  by  the 


loader  entry  point  is  provided  to  user 
they  may  request  loading  or  linking  to 
No  input/output  functions  should  be 
user  routine  . 


31 


introduction  to  file  concept? 


wh»n  the  subroutine  is  placed  on  a Work  Library,  thp 
BntrY  point  nais  and  the  load  Module  name  (PDS  member  na  me) 
must  be  the  same.  The  iuras  aust  be  identical  due  to  the 
requirements  established  for  use  of  the  SUBLPR  utility 
1-cograa. 


3.3.1  Assembly  Language  Routines 

Th»  routine  should  use  the  following  macro  as  its  first 
instruct  ion. 

SUBNAlE  FPSBE3IN  BASERE3 

This  aacro  will  generate  the  proper  CSFCT  and  SAVE 
linkage.  Register  13  will  point  to  a generated  SAVE  area 
and  should  not  be  used  by  the  conversion  routine.  Registec 
i3  AS  E FE3  will  have  been  initialized  as  the  routine  base 
register  along  with  thP  appropriate  USING  statement. 

Register  3 will  point  to  the  parameter  address  constant 
list.  when  returning  ccntrol,  register  15  may  contain  the 
return  code  as  discussed  previously  and  the  following  macro 
usad  to  return  control. 

FFSFETPN  RC=  (15  J 

Otherwise,  the  byte  indicated  by  parameter  three  must  be 
tilled  with  *S  ' or  ' M • . 

The  following  is  an  example  of  an  assembly  language 
su  br out ine: 

//ASM  SUB  EXE:  ASHFCL,PARM.LKED='  HAP, LIST  ,LET  ,DC' 

//ASM.S  YSLIB  DD 

//  DD  DSN=FPS.HACLIB,DISP=SHR 

//ASM.S  YSIN  DD  * 

OTGO  S START 

* A DATE  CONVERSION  ROUTINE 

* CHANGES  PILE  DATE  FROM  YYBNDDTTTT  TO  OUTPUT  AS  DDNHHYY/TITr 

♦LOAD  BASE  REGISTER,  SAVE  CALLING  PROGRAM  REGISTERS,  LINK  TALLIN  Pld 

* 

OT GO  S FFSBEGIN  7 

L 8,4(1)  load  address  OF  DUBBY  SECTION 


32 


I N TP  D DUCT  ION  TO  PILF  CONCEPT? 


USING  PA  H H LI  ST , 8 INIT  PEG  8 


SP 

6 , b 

ZERO  OUT  6 

* 

LA 

M2  (6) 

ADD  12  TO  6 PUT  IN  REG  b 

* NOV  F.  INPUT 

DATE  TO  WORK  APFA,  REFORMAT  DD  AND  Y Y 

•CONVERT 

T HO 

DIGIT  MONTH  TO  SYHBOLIC  THREE  CHARACTERS 

♦PETUPN 

• 

AN  • 

S • SUCCESSFUL  OR  • M' 

UNSUCCESSFUL  IN  PEG  15 

five 

DIGMNTH  (2)  ,P  AP  Hi  POS*2  HOVE  HONTH  WORK  AREA  FOR  COMPARE 

LA 

5,  T ABLE 

LOAD  ADDRESS  OF  TABLE  INTO  REG  3 

LOOP 

CLC 

DIGMNTH  (2)  ,0  (S) 

COMPARE  TWO  DIGIT  MONTH  TO  TABLF 

BE 

FO  J N D 

IP  EQUAL  GO  HOVE  SYMBOLIC  MONTH 

LA 

5,S(S) 

ADD  5 TO  REG  5 and  PUT  IT  IN  PEG 

BCT 

6, LOOP 

FI  IT  IF  R6  GETS  TO  ZERO 

7 i'OP 

IC 

15, =C*  H' 

UNSUCCESSFUL  CONVERT 

HVC 

MONTH  (3)  , = C'IXX  • 

TEMPORARY  FIXER  ***••**• 

B 

DATEOEXT 

GO  TO  EXIT  ROUTINE 

FOUN  D 

IC 

15, =C* S' 

SUCCESSFUL  CONVERT 

HVC 

MONT  H(  3)  , 2(5) 

MOVE  SYMBOLIC  HONTH  TO  WOPK  AREA 

DATED  EXT 

n vc 

DA  Y ( 2)  , PAP  HI  POS*4 

HVC 

YEAP  (2) , PARK  IPOS 

REFORMAT  YEAP 

H VC 

TIHE  (4)  ,PARHlPOS»6 

SAVE  TIHE 

HVC 

PARHLNH*  12  (1  2)  ,WOFK1  HOVE  PEPDPHATTPD  DATE  TO  LIS'* 

PPSRETRN  FC  = (1  5) 

* CO  NS  TAN 

T SECTION 

OS 

OP 

WORK  1 

DS 

d:l12 

WORK 

DAY 

DC 

CL2  • • 

AR  EA 

MONTH 

DC 

CL3  • ' 

REFORMAT 

YEAP 

DC 

CL2  • • 

DATE 

DC 

CLI  •/• 

AND 

T 13  E 

0 

DC 

CL4  • ' 

TIME 

DIG1NTH 

* 

DC 

:l2  • • 

TWO-DIGIT  MONTH  WCRK  AREA 

SAVE 

DS 

lap 

AREA  TO  STORE  REGISTERS 

TABLE 

DC 

C'OIJAN' 

DC 

C'O  2FEB' 

DC 

C • 03HAR  • 

DC 

C'O  4APR' 

DC 

C '05HAY* 
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DC  C06JON* 

DC  C07JUL* 

DC  CC8AUG* 

DC  C • 09SEP • 

DC  C*10  OCT  • 

DC  C • 1 1 NO V 

DC  C ' 1 2DEC* 

* 

«-DUMf!T  SECTION 

* 

OARHLIST  DSFCT 

PAS5LNR  DC  H ' 1 0 1 APGONENT  LENGTH 

PARN1  POS  DS  CLIO'  * ARGUMENT 

DS  C LI  2 FUNCTION  H AX  SIZE 

DC  CL1  ' ' RETURN  CODE 

* 

END 

/* 

//LK  ED.  5 YS  LHOD  D5  N=  T ES T ERL ( DT GOS)  , DISP=OLD 

/* 


3.3.2  COBOL  Dsec  Subroutines 

The  subroutine  is  called  as  follows; 

CALL  'SUBNAHE'  using  DONUT  P2  P3. 

The  first  linkage  parameter  is  provided  for  use  by  assembly 
languaga  routines  only  but  aust  be  accounted  for  by 
COBJL  subroutines. 

LINKAGE  SECTION  . 

71  DUNHI. 

72  NOTHING  PICTURE  X. 

n P2. 

92  APGLEN  PICTURE  S(99)  usage  coiputat  iona  1. 

92  ARGFNC  PICTORE  etc. 

91  P3. 

92  RETURN-CODE  PICTURE  X. 
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CODF  «ust  be  filled  with  *S*  or  *1*  to  indicate 
successful  or  unsuccessful  conversion,  respectively.  ARGLEN 
contains  the  number  of  bytes  in  the  ARGPNC  area  containing 
the  arquaent  data.  Function  data  should  be  inserted  in 
AR3PNC  immediately  following  the  last  argument  byte 
(ARGFNC+N  where  N=nuaber  of  bytes  in  the  argument). 

Th?  following  statements  should  be  inserted  in  the 
PROCFDUPE  DIVISION  -- 

ENTER  LINKAGE. 

"NT3Y  ' SUBNAHE'  USING  UUMMY  P2  P3 . 

ENTER  COBOL. 

Th j following  is  an  example  of  a COBOL  subroutine  which 
serves  the  same  function  as  the  ALC  conversion  subroutine  in 
the  previous  paragraph. 

//C0BSUBS1  EXEC  COBFC L, PAP M ,COB='  H AP , BUF=  12 2 9 2 , N OS  EQ,  LINECNr  = 50* 
//COb. S YSI  N DD  * 

000010  IDENTIFICATION  DIVISION. 

000020  PROGR  A M-  ID.  ' PGMNAM'  . 

000030  ENVIRONMENT  DIVISION. 

000040  CONFIGURATION  SECTION. 

000050  SOURCE-COMPUTER.  IBM-360-50. 

000360  OBJECT-COMPUTER.  IBM-360-50. 

000070  DATA  DIVISION. 

C0C080  LINKAGE  SECTION. 

000090  01  DUMMY. 

0001  00  02  NOTHING  PICTURE  XXXX. 

0001  10  01  P 2. 

000120  02  AFGLEN  PICTURE  XX. 

0001  30  02  IN-YEAR  PICTURE  XX. 

000140  02  IN-MONTH  PICTURE  XX. 

000150  02  IN-DAY  PICTURE  XX. 

0001  60  02  IN-TIME  PICTURE  XXXX. 

000170  02  OUT-DAY  PICTURE  XX. 

0001  30  02  OUT-MONTH  PICTUFE  XXX. 

000181  02  OUT- YEAR  PICTURE  XX, 

000190  02  SLASH  PICTURE  X, 

000200  02  OUT- TIME  PICTURE  XXXI. 
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0010  10  01  P3. 

001020  02  RODE  PICTURE  7. . 

001030  PROCEDURE  DIVISION. 

001040  ENTER  LINKAGE. 

001050  ENT F ¥ 'COBSUB'USING  DUMMY  P2  P 3. 

001060  ENTER  COBOL. 

001070  INITIALIZE. 

0 01  OF  0 MOVE  'S'  TO  RODE. 

001090  MOVE  •/•  TO  SLASH. 

001100  MOVE  ZEROS  TO  OUT-DAY. 

001110  HOVE  ’XXX*  TO  OUT-MONTH. 

001120  MOVE  ZEROS  TO  OUT-YEAP. 

0011  30  MOVE  ZEPOS  TO  OU^-TIMF. 

001140  CHECK-YFAP. 

001150  IP  IN-YEAR  IS  GREATER  THAN  ♦ 49  • , 

001160  OR  IN-YEAR  IS  LESS  THAN  ‘00', 

001170  MOVE  ' M ' TO  PODE  , GO  TO  CHECK-MONTH. 

001180  HOVE  IN-YEAR  TO  OUT-YEAR. 

001190  CHECK-MONTH 


001200 
00201  0 

IP 

IN- MO  NTH  IS  EQUAL  TO 
GD  TO  CHECK-DAY31  . 

•01*  , 

HOVE 

* JAN' 

TO 

OUT- MONTH , 

UO202O 
0020 10 

IP 

IN-MONTH  IS  EQUAL  TO 
GO  TO  CHECK-DAY28. 

•02* , 

HOVE 

• FEB* 

TO 

OIIT-HONTH  , 

002040 

002050 

IP 

IN- HO  NTH  IS  EQUAL  TO 
GO  TO  CHECK-DAY31  . 

•03'  , 

HOVE 

* MAP' 

TO 

OUT- MONTH, 

002060 

002070 

IF 

IN-MONTH  IS  EQUAL  TO 
GO  TO  CHECK-DAY30. 

•04*  , 

HOVE 

• APR* 

TO 

OUT-HONTI!  , 

002090 

002090 

IP 

IN- MO  NTH  IS  EQUAL  TO 
GO  TO  CHECK-DAY31  . 

*0  5'  , 

HOVE 

'HAY* 

TO 

OUT-MONTH  , 

002100 
0021  10 

IP 

IN- MO  NTH  IS  EQUAL  TO 
GO  TO  CHECK-DA  Y30  . 

*06'  , 

MOVE 

* JUN* 

TO 

OUT- MONTH , 

0021  20 

0021  30 

IP 

IN-MONTH  IS  EQUAL  TO 
GO  TO  CHECK-DAY31  . 

• 0 7*  , 

MOVE 

• JUL* 

TO 

OUT- MO  NTH , 

002140 

002150 

IF 

IN- MO  NTH  IS  EQUAL  TO 
GO  TO  CHECK-DA  Y31  . 

•08*  , 

MOVE 

' AUG* 

TO 

OUT- MONTH , 

0021  60 
002170 

IF 

IN- MO  NTH  IS  EQUAL  TO 
GO  TO  CHECK- DA  Y3  0 . 

• 09*  , 

MOVE 

• SEP' 

TO 

OUT- MON  Til, 

002180 

002190 

I? 

IN-HoNTH  IS  EQUAL  TO 
GO  TO  CHECK-DA  Y31  . 

• 10*  , 

HOVE 

'OCT* 

TO 

OUT- MONTH , 

002200 
00301 0 

IP 

IN-HONTH  IS  EQUAL  TO 
GO  TO  CKECK-DAY30. 

•If  , 

MOVE 

• NO  V* 

TO 

OUT-  MON  TH  , 

0 0 JO  2 0 
0030  30 

IP 

IN-HONTH  IS  EQUAL  TO 
GO  TO  CHECK-DA  Y31  . 

• 12*  , 

MOV  E 

' DEC' 

TO 

OIIT-HONTH  , 

< 
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D03  340  MOVE  • H*  TO  RODE. 

003050  CHECK-DA  Y31. 

003060  IP  IN-DAY  IS  GREATER  THAN  *00', 

003070  AND  IN-DAY  IS  LESS  THAN  •32',  MOVE  IN-DAY  TO  OUT-DAY, 

003030  GO  r C CHECK-TIME. 

003090  MOVE  'M*  TO  RODE,  GO  TO  CHECK-TIME. 

0031  00  CHECK-D AY30 . 

003110  IF  IN-DAY  IS  GREATER  THAN  *00*, 

0031  20  AND  IN-DAY  IS  LESS  THAN  *31',  HOVE  IN-DAY  TO  OUT-DAY, 

003  1 30  GO  TO  CHECK-TI  ME  . 

0031  40  MOVE  ' H ' to  RODE,  GO  TO  CHECK-TIME. 

003150  CHECK-DAY26. 

003 1 bO  IP  IN-DAY  IS  GREATER  THAN  *00', 

0031  70  AND  I N=D  A Y IS  LESS  THAN  *29',  MOVE  IN-DAY  TO  OUT-DAY, 

003  1 R0  GO  TO  CHECK-TIME. 

003190  MOVE  ' H • TO  RODE. 

003200  CHECK-TIME. 

004010  IP  IN-TIME  IS  GREATER  THAN  '00*, 

004020  AND  IN-TIME  IS  LESS  THAN  * 2401', 

004030  HOVE  IN-TIME  TO  OUT-TIME,  GO  TO  DEFART. 

004040  MOVE  • M*  TO  RODE. 

004050  DEPART. 

004060  IF  RODE  IS  NOT  EQUAL  TO  * M' , HOVE  * S’  TO  RODE. 

004070  ENTER  LINKAGE. 

004  090  GOBACK. 

004090  ENTER  COBOL. 

/* 

//LKED.S YSLMOD  DD  DSN=TESTERL  (COBSUB)  ,DISP=OLD,UNIT-2314 
//LKED.  SYS  IN  DD  * 

ESI  TR  Y COBSUB 

/* 

Note:  The  linkage  editor  control  card,  ENTRY  COBSUB,  is 

necessary  for  a COBOL  subroutine  (this  naae  must 
correspond  with  the  naae  of  the  subroutine  as 
defined  on  the  ENTRY  stateaent  in  the  PROCEDURE 
DIVISION  and  on  the  LKED.SYSLHOD  DD  stateaent). 


3.3.3  P L 1 User  Subroutine 

PL1  user  ..subroutines  require  an  asseably  language 
interface  in  order  to  be  called  by  a NIPS  application 
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prograa.  The  asseably  language  routine  sets  up  the  dope 
vectors  required  to  pass  paraaeters  to  the  PLl  subroutine. 
A complete  discussion  of  asseably  language/PLI  interface 
conventions  can  be  found  in  the  PLl  Prograaaing  Guide. 

An  exanple  of  JCL,  asseably  language  interface,  and 
sample  PLl  subroutine  is  shown  in  the  following  section  of 
code . 


//3TEP1  EXEC  ASMFC  F,PARfl.ASN='  LOAD  NODECK*  ,REGION=  1 14K 
//A SM.SYSLIB  DD  DS  N=  FFS  . JOBKACRO,  DISP  = S HP 
//ASM  . S Y SI  N DD  * ASEM  TYPEIN 

//STEP2  EXEC  PLIXCL,  REGION  =1  2 OK,  P ARM.  PLI='  MAP'  ,PAPM,  LKED=  'LET  ' 
PLI.SYSIN  DD  * PLISUB  TYPEIN 

//U ED.SYSLBOD  DD  D SN  =6TF  HP  (FFEDIX)  ,U  NIT=  S YS  D A,  S P AC  (TFK,  (10,  1,1)), 

//  DISP=  (NEW,  FASS) 

/ASED.SYSIN  DD  * 

NAME  PREDIX  (R) 

ENTRY  PR  EDIT 

//STEP3  EXEC  XSOBLDR,VLT£-»SEP*KXEXXX*  ,L  IB*TSTLIB,»IUB=231  4 , 

//  LIBDISP=0LE,BLK=61  *44 

//SYSIN  DD  * 

SUBRT  P 3 ED  IX  18  100  BAA  PREDIX  LEWISER 

/* 

//ST  EP  4 EXEC  X SUBCHK,  LI  B*TSTLIB,  ULI  B*2  3 1 4 
//  VLIB= ,SER=XXXXXX* 

//SUBCHK  .XYZ  DD  5 YSOUT=A , DC  B*  ( F ECFN  = V B A ,LPECL=  1 37  , BLKSIZE=1  5 00) 
//SUBCHK.  ABC  DD  S YS  CUT* A,  DC  B=  (R  ZCFM  = V BA  , L REC L=  1 37  , B IKS  IZ E*  1 50 0) 
//SUBCHK.  PLIDUHP  DD  SYSOUT=A 
//SUBCHK. SYSUDUMP  DD  SYSO^-A 
//SUBCHK.  S YSIN  DD  * 

PREDIX  018 

♦E  53  96213764666  25  7 
/* 


♦THIS  ASSEMBLY  LENGUAGE  POUTINE  NAS  BRITTEN  AS 
♦NIPS  AND  PLl. 

♦THE  NAME  OF  THE  POUTINE  IS  PREDIX.  ANY  PERSON 
♦ INTERFACE  CAN  USE  THIS  CODE, 


AN  INTERFACE  BETH  SEN 
NEEDING  A NIPS/PU 
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* 

* 

P R ED  IX 


P ARBS 


ADLIST 


IN  1 

INPUT 

OUT1 

OUTPUT 

RC1 

RC 


FPSBEGIN  12 

R EG  3 PONTS  TO  THE  NIPS  AREA 
L 3,4(1) 

H?C  INPUT  ,2  (3) 

LA  1, PARKS 

L 15, =V  (PLICA  LLB) 

BALR  14, 15 

H VC  20(100,3)  , OUTPUT 
SR  15,15 

IC  1 5,  RC 

PFSRETRN  RC=  (15) 

DC  A (ADLIST) 

DC  A(D) 

DC  A (0) 

DC  A (0) 

DC  A (0) 

DC  X*80« 

DC  AL3  (0) 

DC  A (I N 1 ) 

DC  A(OUTI) 

DC  X ' 80 ' 

DC  AL3  (RC1) 

DC  A (INPUT) 

DC  2AL2  (L' INPUT) 

DC  C LI  8 ' • 

DC  A (OUT  PUT) 

DC  2AL2 (L'OUTPUT) 

DC  A Li  00  ' ' 

DC  A (RC) 

DC  2AL2 ( L*  RC) 

DC  C*  • 

END  PRBDIX 


PRED  : PROCEDIJRE(  INPUT,  OUT,  RC)  OPT  ION  S (M  A IN  ) REORDFP; 

DC L XYZ  PILE  PRINT  OUTPUT  STREAM; 

DCL  SYSPRINT  FILE  PRINT  OUTPUT  STREAM; 

DCL  INPUT  CHAR  ( 18)  ; 

DCL  OUT  CHAR  (1  00)  ; 

DCL  RC  CHAR  (2)  ; 


39 


INTRODUCTION  TO  FILE  CONCEPTS 


DCL  IC  CHAP  (2)  I NZ  ?I  AL  ('  S 

OPEN  PILE  (STSPPINT)  TITLE  ('ABC’) 

PUT  FILE  (XTZ)  SKIP  EDIT  <•  WE  HAVE  FNTEPFD  THE  PLI  POU 
(A)  ; 

PUT  FILE  (XYZ)  P0IT  (INPUT)  (A); 

RC  = IC  ; 

PETUPN; 

END; 


3.3,4  User  Scan  Subroutine 

If  the  System  Scan  subroutine  for  use  with  the  Keyword 
Indexing  capability  does  not  meet  a user's  needs,  he  can 
write  a Scan  subroutine  of  his  own.  See  the  Keyword 
Indexing  section  for  a description  of  the  System  Scan 
SunroutLne.  The  user  must  specify  the  name  of  his  routine 
in  each  Keyword  indexed  field  entry  in  the  FPT  that  is  to  b<=> 
scanned  by  it  (see  Volume  II,  File  Structuring  Index 
Definitions  for  Keyword  Fields).  When  he  codes  the 
subroutine  he  must  conform  to  general  NIPS  subroutine 
interface  requirements  and  he  must  meet  the  following  Scan 
Processor  interface  requirements; 

a.  The  subroutine  must  distinguish  a call  to  scan  a 
new  field  from  a call  to  resume  scanning  a current 
field.  The  return  code  byte  in  the  parameter  list 
may  be  used  for  this  purpose. 

b.  The  subroutine  mu3t  accept  thB  following  parameter  list 
from  the  scan  Processor  (the  controlling  routine): 

P - address  of  the  field  to  bo  scanned. 

P - scan  limit;  address  of  the  field  plus  its 
length  minus  i. 

P - address  of  ths  caller's  word  hold  area. 

CL1  - hyphen  option  byts  from  the  FPT  for  the  field 
be  in  g s canned  . 
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Por  information  aaout  defining  This  byte  in  the  FFT 
and  for  the  system  interpretation  of  it,  refer  to 
the  Index  Definition  for  Keyword  Fields  section  of 
volume  II,  File  Structuring  - Index  Definitions  for 
Keyword  Pields,  and  to  the  Keyword  Indexing  section 
(3.7)  of  this  volume. 

The  user's  scan  aay  ignore  this  byte  or  it  nay 
interpret  it  any  way  it  pleases.  The  byte  contains 
one  of  the  following  binary  values: 

1 - DP  OP 

2 - PETAIN 

3 - SEPARATE 

4 - TEXT  (def»  ult) 

CL1  - return  code  byte;  the  scan  subroutine  eust  place 
a return  code  in  this  byte  before  it  returns  to 
the  scan  processor.  The  scan  processor  does 
not  modify  the  byte  unless  it  loads  a new  scan 
subroutine,  at  which  time  it  sets  an  end-of- 
scan  indicator. 

c.  It  must  return  on?  word  in  the  caller's  word  hold 
area  in  the  following  format; 

CL1  - length  of  the  word. 

CL30  - recovered  word,  left- justified. 

It  aust  set  bit  0 of  the  length  byte  to  1 if  the 
recovered  word  is  a literal.  This  flag  bit  is  used 
to  bypass  dictionary  processing  of  literal  words. 

d.  It  must  return  on?  of  the  following  codes  in  the 
paraaeter  return  code  byte  each  time  it  returns  to 
the  scan  processor 

0 - a word  was  recovered;  there  is  more  data 
to  scan. 
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4 - a word  was  recovered;  end-of  scan. 

8 - no  word  recovered;  end-of-scan. 

The  scan  processor  will  recall  the  scan  subroutine  to 
continue  processing  the  saae  field  if  the  scan  subroutine 
returns  a xero.  Otherwise,  it  will  assume  that  all  words 
have  been  recovered  from  the  current  field.  If  there  are  no 
more  fields  to  process,  it  will  not  recall  the  scan 
subroutine  (i.e.,  there  is  an  end -of-f ile)  . 


3.4  Definition  of  Edit  flasks 

The  user  writes  an  edit  mask  in  a language  statement  as 
a literal.  That  is,  single  quote  signs  are  used  for 
delineation.  The  edit  capability  of  NIPS  360  PFS  permits 
the  user  the  following  features  when  applied  to  a numeric 
data  value; 

a.  Zero  suppression 

b.  Sign  control  left  or  right 

c.  Leading  and  trailing  significant  characters 

d . Character  insertion. 


Th 3 remainder  of  this  section  discusses  the  techniques  of 
writing  an  edit  mask. 

Any  character  which  can  be  printed  may  be  used  in  the 
adit  mast  except  a quote  mirk.  However,  certain  characters, 
namely  ampersands,  blanks,  and  zeros,  will  not  appear  as 
such  in  the  output.  Purths  rmore , minus  or  credit  (CR) 
symbols  have  special  meanings.  One  character  position  in 
the  output  is  represented  by  one  character  in  the  edit  mask. 
Nonspecial  characters  in  the  mask  will  be  printed  in  the 
same  relative  position  in  the  output  field.  A mask  may  be 
132  characters  long;  however,  certain  NIPS  components  have 
shorter  limits.  As  in  most  cases,  since  no  more  than  10 
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replaceable  characters  (blanks  or  zeros)  can  be  filled  by 
source  data,  edit  casks  should  tend  to  be  less  than  70 
characters  long. 

The  actions  taken  for  each  special  character  in  the  edit 
mask  are  given  below. 

Blame  --  Each  blank  in  the  edit  cask  will  be  replaced  by 
a digit  from  the  source  field. 

Zero  --  each  zero  in  the  edit  nask  will  be  replaced  by 
a digit  from  the  source  field,  and  the  leftmost  zero  will  be 
the  right  lost  limit  of  zero  suppression. 

Ampersand  --  Each  ampersand  in  the  edit  nask  will  be 
replaced  by  a blank  in  the  output  field. 

Minus  sign  --  If  the  ninus  sign  is  to  the  left  of  the 
first  replaceable  character  or  to  the  right  of  the  last,  it 
is  considered  a sign  control  character.  If  the  sign  field 
is  negative,  the  minus  sign  and  any  other  nonreplaceable 
characters  occurring  with  it  are  printed.  If  the  sign  is 
positive,  neither  the  ninus  sign  nor  the  acconpanying 
characters  are  printed. 

CR  --  If  the  character  C is  immediately  followed  by  the 
character  R on  the  left  of  the  first  replaceable  character 
or  on  the  right  of  the  last  replaceable  character,  they  are 
considered  as  sign  control  characters,  and  are  treated  just 
like  a ninus  sign. 

The  followiig  examples  should  clarify  the  use  of  these 
special  characters. 
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Hdi  t M §sk 

Source 

Re  suit 

• bbDbb ' 

12345 

12345 

00001 

bbbOl 

• XXCR&flbbXZ  • 

123 

bbbbbl  2 37X 

-123 

2XCFbL2.m 

001 

bbbbbbO  1Z  X 

-001 

.TXCRbbOlXZ 

•$. bb-  • 

12 

j:.  12b 

-12 

$.12- 

01 

S.Olb 

-01 

$.01- 

• Ob/bb/bb » 

01016ft 

bl/01/6  P 

In  output,  if  the  size  of  the  source  field  is  known  when  the 
edit  mask  is  first  processed,  a test  is  made  to  see  whether 
that  many  replaceable  characters  exist.  If  the  source  is 
too  long,  the  edit  mask  is  rejected.  If  the  source  is  too 
short,  the  system  will  start  at  the  left  an  d replace  the 
Dlanks  and  zeros  with  ampersands  until  the  desired  number  of 
replaceable  characters  remain.  This  occurs  before  the  test 
for  CR  and  -,  but  after  the  test  for  zero.  Thus,  a mask  of 
0-hoh  for  which  a 3-character  source  field  is  specified  will 
cause  a 001  field  to  be  printed  as  bbOOl. 

If  the  size  of  the  source  field  is  not  known  when  the 
adit  mask  is  first  processed,  the  system  will  count  the 
number  of  replaceable  characters  and  return  this  number  to 
the  calling  program. 

In  Pile  S true tur i ng (PS)  , the  replaceable  characters  in 
a defined  edit  mask  and  the  field  which  is  defined  to  use  it 
must  be  of  equal  length. 


3.5  Maintenance  of  Source  Language  Programs 

In  a large  installation,  keeping  track  of  source  decks 
oecomes  a real  problem,  source  decks  for  NIPS  components 
may  be  maintained  on  direct  access  libraries  to  facilitate 
h oust kaa pi ng  and  source  program  maintenance.  Source  can  be 
stored  on  a library  by  the  Nr  PS  batch  components  and  the 
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UTSOUPC  utility  program.  Fro* 
component  of  the  Terminal  Processing 
maintain  source  libraries. 


a term  ir>  a 1,  t he  EDIT 
System  can  bo  used  to 


3.6  Secondary  Indexing  Capability 

Secondary  Indexing  provides  the  user  with  the  capability 
to  index  any  ISAM,  S AH  or  ? S AM  file  by  the  contents  of  a 
field  or  fields  other  than  the  Record  ID.  The  primary 
purpose  of  the  capability  is  to  provide  a faster  response 
time  for  qualifying  data  records  during  retrievals. 

Secondary  Indexing  encompasses  three  basic  areas:  Index 
Specification,  which  allows  the  user  to  specify  fields 
and/or  groups  which  are  to  be  added  (or  deleted)  as  indexes; 
Index  Maintenance,  which  ensures  current  and  accurate 
indexing  information;  and  Index  Processing  which  uses  this 
information  in  the  retrieval  process. 

The  fields  and  groups  which  are  to  be  indexed  are 
designated  during  File  Structuring  (FS)  or  Index  Specifier 
(UxNDXSPC)  runs.  From  that  point  on,  all  Secondary  Indexing 
functions  occur  automatically,  transparent  to  the  user,  and 
cannot  be  overridden,  except  in  the  case  of  retrieval. 


The  user's  prime  concern  in  the  use  of  Secondary 
Indexing  is  the  judicious  choice  of  index  fields.  These 
fields  slould  be  chosen  on  the  basis  of  expected  frequency 
of  use  in  retrievals.  Choosing  too  few  indexes  would  limit 
the  effectiveness  of  the  capability  while  choosing  too  many 
wouid  load  down  the  capability  with  needless  overhead  costs. 


Since  the 
Indexing  only 
section  will 
Specification. 


user  interfaces  directly  with  Secondary 
during  Index  Specification,  the  rest  of  this 
discuss  the  techniques  involved  in  Index 


Regardless  of  whether  an  index  is  specified  as  part  of 
an  FS  run  or  by  using  the  stand-alone  Index  Specifier 
(UTNDXSPC)  , an  Index  Specification  statement  is  required  and 
includes  the  items  listed  belov; 
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o Statement  identifier  - INDEX 

o Name  of  fitild/group  to  be  indexed 
o Action  1 3 be  taken  (ADD  or  DELETE) 

o Conversion  or  analyzer  routine,  or  table  (optional) 

If  a conversion  or  analyzer  routine  or  table  is 
specified  on  the  index  Specification,  the  routine  or  table 
must  have  been  previously  defined  on  a SUB/TAB  stateaent. 
This  statement  contains  th>  following  information. 

o Statement  Identifier  - SUB,  SUBROUTINE,  TAB,  ol 
TABLE 

o Name  of  subroutine  or  table 

o Punctioa  (CONVERT  or  ANALYZE)-for  subroutines  only 
o Input  and  ourput.  lengths  of  data 

o Mode  of  input  and  output  data  - applicable  only 
(ALPHA,  BINARY,  COORD,  or  DECIMAL)  tor  CONVERT  sub- 

ro  utines 

As  aantioned  above,  once  the  indexes  for  a file  are 
specified,  no  further  user  actions  are  required  to  use  the 
Secondary  Indexing  capability.  Pile  updating  by  PM  or  SODA 
causes  routines  to  generate  corresponding  transactions  to 
upiate  the  indexes.  RASP  or  QUIP  will  use  the  information 
provided,  wherever  possible,  in  order  to  improve  retrieval 
iff  Lciincy. 

More  detailed  information  regarding  the  Index 
Specification  and  associated  SUB/TAB  statements  is  contained 
in  Voluis  II,  Pile  structuring.  Information  regarding  usage 
of  indexes  will  be  found  in  Retrieval  and  Sort  Processor, 
Volume  IV,  and  Terminal  Processing,  Volume  VI. 


46 


INTR3  DUCTION  TO  FILE  CONCEPT? 


1.7  Keyword  Indexing  Capability 

Kpyword  Indexing  is  a t ax  t - r*  tr  ia  ra  1 capability  that 
provides  a aethod  by  which  the  NIPS  user  can  access  and 
retrieve  records  based  upon  the  contents  of  variable-length 
oi  ♦ext  data  fields.  Just  as  Secondary  Indexing  enables  » 
user  to  query  a file  and  access  only  those  data  records 
known  to  contain  the  fixed-length  fields  of  interest  to  hia, 
keyword  Indexing  enables  the  user  to  retrieve  records  based 
on  the  prssence  of  'keywords*  within  a field.  To  provide  a 
capability  tailored  to  his  needs,  the  user  has  options  to 
dn?ct  the  selection  of  'keywords*  froa  the  indexed  field. 
This  selection  is  based  on  the  presence  or  absence  of  a stop 
wor!  table  and  a dictionary.  These  tables  ace  user  provided 
and  are  designated  at  the  field  level,  although  one  table 
may  bp  applied  against  sore  than  one  field. 

A stop  word  table  consists  of  a list  of  irrelevant 
(noisei  words.  Any  words  found  in  this  table  are  eliminated 
froa  further  consideration  as  keywords.  The  primary 
advantage  of  the  stop  word  table  is  the  reduction  of  th«> 
number  of  words  which  eust  be  sorted  (and  watched  against  a 
dictionary  if  one  is  specified)  . A systea  stop  word  table 
naxsd  ICKSTOP  is  available  to  the  user.  It  contains  the 
following  words: 


A 

BY 

IS 

OR 

USE 

A FT  PP 

CAN 

IT 

P E 

USED 

ALLOW 

COULD 

MODE 

SINCE 

WAS 

AM 

EV  FN 

MORE 

SO 

WE 

AN 

F VP? 

NO 

THAT 

WHPN 

AND 

EVERY 

NOT 

T HE 

W HER  E 

ANT 

POP 

NON 

THEN 

WHEREAS 

BE 

HAS 

OP 

THIS 

WHICH 

BEEN 

IF 

ON 

TO 

WILL 

BUT 

IN 

ONLY 

UNDER 

WITH 

A dictionary  consists  of  words  which  are  potential  index 
1 a ti  set  entries  or  synonyas  for  potential  entries.  For 
exanple,  the  following  values  are  to  qualify  as  keywords  - 
Aircraft,  Bomber,  Plane  and  Fighter.  Por  retrieval  purposes 
these  values  are  synonoaous  and  are  entered  into  the 
dictionary  as  such.  The  index  data  set.  will  carry  the  ID  of 
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ji:i  record  where  any  of  these  values  occurred  in  the 
designated  field.  Then,  when  a retrieval  is  «ade  against 
this  field  with  a keyword  argument  of  either  Aircraft, 
tioiDer,  Fighter  or  Flane,  all  records  containing  any  of 
these  values  in  the  indexed  field  will  gualify.  The  aaxiiui 
valup  langth  of  a keyword  is  10  characters. 

when  a data  word  is  Batched  against  a stop  word  table  it 
oust  exactly  aatch  the  table  word  to  be  eliminated  froa 
further  processing.  When  a data  word  is  aatched  against  a 
dictionary,  however,  the  entire  data  word  need  not  exactly 
mt:h  a dictionary  word  because  of  two  functions  - suffix 
processing  and  suffix  specification. 

SiltLiA  Ptogess  jpg  - Suffix  Processing  is  an  autoaatic 
programming  function  that  is  conditionally  applied  to 
all  arguient  words  aatched  to  a dictionary.  Suffix 
specification  is  a control  stateient  notation  which 
peraits  a user  to  indicate  keyword  ending  changes  when 
a keyword  is  suffixed.  If  a keyword  exactly  Hatches  the 
Host  significant.  (left -most)  characters  of  a longer 
arguient  word,  the  unaatched  argument  characters  are 
anaLyzed  to  determine  if  they  are  a suffix  to  the 

matched  keyword.  The  unaatched  characters  are  looked  up 
in  a table  of  acceptable  suffixes.  If  they  exactly 
match  a table  entry,  the  ending  characters  of  the 
keyword  are  examined  to  determine  if  the  latched  suffix 
can  be  validly  attached  to  thei.  If  they  pass  the  test, 
the  keyword  is  substituted  for  the  argument  word.  Note 
that  a double  substitution  could  be  required;  the 

keyword  could  be  a convert  keyword  (synonyi),  in  which 
cas;  the  synonyi  base  keyword  is  substituted  for  the 
arguient . 

Syltii  _5ES£iIiS.ili2D  ’ If  a user  specifies  to  the 
Dictionary  Maintenance  utility  that  a keyword*s  ending 
changes  when  the  word  is  suffixed,  the  changed  fori  of 
the  word  is  stored  in  the  dictionary  as  an  independent 
keyword  with  the  restriction  that  if  an  arguient  word 

exactly  latches  the  changed  for*  of  the  word,  that 

arguient  is  sot  a keyword.  In  other  words,  the  changed 
fori  of  the  keyword  lust  latch  the  significant 
characters  of  a longer  argunent,  and  the  unlatched 
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-r._  ..  :'A 

argument 

characters  sust  be  a 

valid  suffix  (see  Suffix 

Processin 

g).  If  these  conditions  are  set,  the  unchanged 

1 

fore  of  the  word  (or  its  associ 

ated  base  keyword  if  the 

word  is 

a convert  keyword) 

is  substituted  for  the 

I 

argueent . 

Table  of  All  Valid 

Suf  f lies 

i 

] 

ABLE 

EPS 

ITION 

ABLeS 

ESI 

IT  IONS 

i 

1 

AGE 

PUL 

ITY 

AGED 

FULLT 

IV  E 

j 

AGES 

IBLE 

IVB3 

< 

AL 

IBLES 

LIES 

* 

ALLY 

IC 

LT 

1 

ANCE 

ICATION 

flENT 

ANCES 

ICATIONS 

NESS 

< 

ATI  OK 

ILIES 

NESSES  , 

ATION  S 

ILITIES 

OP 

ATI  VF 

ILIU 

B (when  preceded  by  E) 

ATIVES 

ILY 

PS(whan  preceded  by  E) 

D(wien  preceded  INAL 

s • , ' / ' ' 

by  E) 

DS(when  preceded  Ing 

SION 

by  E) 

ED 

INGS 

SIONS 

EDS 

ION 

TIES 

ENCE 

TONAL 

TIOW 

ER 

ITIES 

TY 

Y(when  preceded  by  L 

or  T) 

i 

Litera Is 

in  the  data  file  are 

never  Matched  against  a 

stop  word  table  or  a dictionary.  Each  Uteral  automatically 

beooeos  a index  data  set  entry.  A 

literal  is  defined  as  all 

characters,  including  blinks,  which  appear  between  two 
single  quotation  aarks  in  the  same  subset  record.  The  user 
should  analyze  t.he  content  of  his  file  so  that  he  eay  select 
those  keywords  which  are  best  suited  for  retrieval  1 gic. 

For  a detailed  description  of  how  to  generate  and 
eaintain  these  tables,  see  Voluee  VII,  Utility  Support, 
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Dictionary  Maintenance  section.  Tables  are  deleted  by  using 
the  OS  Utility  IEHPROGH 

Uss  and  content  of  tables  should  be  based  on  the  nature 
of  the  iata.  If  no  tables  are  specified,  each  value  found 
within  the  indexed  field  becomes  an  entry  in  the  index  data 
sat.  Tbs  user  should  analyze  the  data  content  of  his  fil 
so  that  he  may  select  those  keywords  which  are  best  suite 
toe  retriaval  logic.  For  efficient  operation,  extraneous 
words  not  used  as  a basis  for  retrieval  should  not  be 
cattle!  as  keyword  entries  in  the  index  data  set.  If  an 

indexed  field  holds  a large  amount  of  text  data,  it  would 
most  likely  be  beneficial  to  have  both  a stop  word  table  and 
a dictionary.  If  a field  contains  ‘keywords*  interspersed 
with  noise  words,  a stop  word  table  would  he  applied  against 
it.  But  if  a field  consists  aainly  of  retrieval  based  words 
with  synonym  or  suffix  (e.g.,  plural  ending)  functions,  only 
a dictionary  need  be  applied. 

Keyword  indexing  adheres  to  the  same  basic  rules, 
considerations  and  functions  as  does  secondary  indexing  and 
applies  to  the  three  areas  of  index  specification, 
maintenance  and  retrieval. 

Indexed  fields  are  defined  through  Pile  Structure,  Pile 
Revision  or  the  Index  Specification  utility  (HTNDXSPC).  Any 
variable  field,  variable  set  or  fixed-langth  alpha  field 
defined  for  the  file  may  be  designated  as  a keyword  indexed 
field.  There  is  no  limit  to  the  number  of  indexed  fields. 
A fixed-length  field  may  not  be  defined  as  both  a secondary 
and  keyword  index.  An  Index  Specification  statement 
consisting  of  the  following  items  is  required  for  each 
indexed  field: 


Statement  Identifier  - INDEX 
Name  of  field/set  to  be  indexed 
Action  (ADD  or  DELETE) 

Text  Retrieval  - KEYWORD 


SO 
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Stop  Work  Table  (Optional) 

Dictionary  (Optional) 

User-Scan  Routine  (Optional) 

Hyphen  Option  (Optional) 

For  each  stop  word  tibia,  dictionary  or  user-scan 
routine  specified,  a SUB/TAB  statement  must  have  been 
included  to  define  the  named  function.  This  statement 
consists  of  the  following  information: 

Statement  Identifier  - SOB,  SUBROUTINE.  TAB 
or  TABLE 

Use  Function  - STOP,  DICT,  DICTIONARY  or  SCAN 

This  action  creates  Index  Descriptor  Records  in  the  PFT. 
Tha  presence  of  these  records  causes  Index  Maintenance  to  be 
invoked  either  through  Pile  Maintenance  or  the  Index 
Specification  utility. 

Tha  generalized  system  scan  routine  in  Index  Maintenance 
processes  the  keyword  indexed  field(s)  of  the  transaction 
records  looking  for  textual  words  and  literals.  It 
determines  the  limits  of  words  by  identifying  literals  and 
text  words. 

For  literals,  the  system  scan  subroutine  recognizes  a 
single  quote  as  a literal  word  delimiter.  All  characters 
between  the  single  quotes  except  double  quotes  are  recovered 
to  form  one  literal  word.  Any  number  of  double  quotes  may 
appear  between  the  single  quotes;  all  are  deleted  during 
recovery.  If  an  odd  number  of  single  quote  characters 
appear  in  a field,  no  word  (literal  or  textual)  will  be 
recovered  between  the  last  single  quote  and  the  end  of  the 
f iaid . 

For  nonliterals  (text  words),  the  system  scan  subroutine 
recognizes  three  categories  of  characters:  textual, 
superfluous,  and  word  separator. 
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Textual  - 


Supjtf  Luous 


Woci 

Separator  - 


Those  data  word  characters  that  are 

recovered  to  fora  the  work  passed  to  the 
subroutine  caller. 

Those  data  word  characters  which  are 

deleted  froi  the  word  passed  to  the 
systea  scan  subroutine  caller.  They  are 
imbedded  in  one  word;  they  separate 
segments  of  one  word. 

Those  characters  in  the  data  field 

that  are  not  part  of  a word.  They  are 

word  delimiters. 


Letters  and  nuibers  are  always  tertual.  The  period  and 
hyphen  aay  be  textual,  superfluous,  or  word  separators.  The 
coma  lay  be  superfluous  or  a word  separator.  A single 
quote  is  a word  separator  as  well  as  a literal  word 
delimiter.  A double  quote  is  ignored;  it  is  a word 
separator  if  another  word  separator  precedes  or  follows  it; 
otherwise  it  is  superfluous.  All  other  characters  are  word 
sepa  rators  . 


Period  Rules  - A period  is  recovered  as  a textual 
character  when  it  appears  in  a word  coaposed  entirely  of 
numbers.  One  or  aore  periods  are  superfluous  if  they 
are  used  to  punctuate  a syabol  (i.e.,  O.S.A.).  The  word 
in  which  they  appear  aay  be  coaposed  of  letters  or 
letters  aixed  with  nuabers.  For  all  other  occurrences, 
the  period  is  a word  separator. 

Coma  B ul es  - One  or  aore  corneas  are  superfluous  if  they 
ara  used  to  punctuate  a nuaber;  that  is,  when  they 
appear  in  a wpc  d composed  entirely  of  numbers  or  of 
nuabers  and  a period.  Por  all  other  occurrences,  the 
coaaa  is  a ,ywocd  separator. 

singly  .Quote  Buies  - Single  quote  is  always  a word 
separator  as  well  as  a literal  word  delimit er. 


Dgjibl e Oupte  ..Rules  - All 
ar;  ignored,  if  it  is 
superfluous,  otherwise  it 


occurrences  of  a double  quote 
imbedded  in  a word,  it  is 
is  a word  separator. 
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H^bea  g ules  - Treatment  of  hyphens  is  dependent  upon 

the  hyphen  option  specified  by  the  user  in  the  EFT . 

Pefer  to  the  Index  Definition  for  Keyword  Fields  section 

of  Volume  II,  File  Structuring,  for  these  options. 

If  the  nature  of  the  data  is  such  that  it  does  not  lend 
itself  to  the  system's  scan  routine,  the  user  may  write  and 
designated  his  own.  P or  a detailed  description  on  the 
requireiants  for  a user's  scan  routine,  see  the  user  Scan 
Subroutine  (section  3.3.4). 

If  a Stop  word  Table  had  been  specified,  each  word  is 
passed  against  it  searching  for  a aatch.  when  a natch  is 
found,  the  word  is  eliainated  froa  any  further  processing. 
Tha  reaaining  words  (or  all  words  froa  the  field  when  no 
Stop  word  Table  is  specified)  becoae  keyword  candidates. 

After  all  transaction  records  have  been  processed,  the 
index  data  set  is  updated.  When  a dictionary  is  not 
specified  for  an  indexed  field,  all  keyword  candidates 
become  entries  in  the  index  data  set.  When  a dictionary  is 
specified,  each  non-literal  word  is  passed  against  it  to 
determine  if  the  value  qualifies  as  a keyword.  An  entry  is 
made  in  the  index  data  set  for  each  qualifying  value;  the 
reaainier  are  dropped  froa  any  further  processing.  Literal 
words  always  qualify  without  being  aatched  to  the 
dictionary. 

To  perform  record  qualification  based  on  keywords,  the 
user  must  include  a KEYWORD  statement  in  his  query. 
Structually  and  functionally,  the  statement  is  siailar  to  an 
IF  statement.  The  same  rules  of  logic  apply.  The  statement 
is  on  the  same  level  of  hierarchy  as  the  LIMIT  statement  in 
UUIP  and  the  secondary  LIMIT  stateaent  in  P AS P.  Only  one 
KEYWORD  stateaent  per  query  is  allowed.  The  format  is  as 
follows: 

KEYWOPD  fieldname  INCLUDES  keyword  argunent(s)  AND. . . claut  e. 

clause  OB 

Each  field  naae  must  have  been  defined  as  a keyword 
indexed  field  or  the  retrieval  will  be  terminated.  The 
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keyword  argument  is  passed  against  the  dictionary  (if  one 
were  specified)  and  against  the  keyword  entries  for  that 
ti»ld  in  the  index  data  set  to  determine  which  records 
qualify . 

This  list  of  record  IDs  is  passed  to  the  retrieval 
routina  to  indicate  what  records  should  be  accessed.  The 
keyword  fields  will  not  be  scanned  again  as  they  have 
already  qualified.  Retrieval  is  on  the  record  level  only, 
when  any  of  the  queried  fields  have  been  defined  as 
secondary  indexed  fields,  such  that  a second  qualifying  list 
is  present,  the  two  lists  will  be  merged  into  one  final  list 
containing  only  those  records  that  qualify  for  both  the 
keyword  and  secondary  indexed  fields. 

Keyword  indexing  is  designed  to  provide  retrieval  based 
on  the  occurrence  of  'keywords'  within  a field.  To  achieve 
optimum  utilization,  the  user  responsible  for  defining  the 
iniaxed  fields  must  have  a good  knowledge  of  the  text  data 
in  the  file  and  the  teras  that  will  be  used  as  a basis  for 
retrieval.  This  is  necessary  in  order  to  define  the  best 
method  of  selecting  keywords  fcoa  a designated  field  (via 
stop  word  table,  dictionary)  and  to  avoid  overloading  the 
indax  data  set  with  fields  and  entries  that  art  unlikely 
candidates  for  retrieval. 

The  Keyword  Analysis  Utility  (see  Voluae  VII#  Utility 
Support)  is  provided  to  assist  the  user  in  naking  this 
selection  for  a file  already  in  existance.  The  contents  of 
any  fialus  in  Ll.e  file  aa y be  listed'  to  determine  the 
likely  candidates  for  indexing  and  what  values  are  likely  to 
be  keywords  or  entries  in  a stop  word  table  and  dictionary. 
This  will  also  assist  in  determining  whether  a stop  word 
table  and/or  a dictionary  should  be  applied  against  the 
field. 


3.9  Interfile  Output  (IPO) 

Interfile  Output  (IPO)  is  the  capability  to  coabine  data 
from  several  related  files  during  the  output  processing.  It 
is  available  In  the  batch  environment  in  the  OP  and  QUIP 
components  and  in  the  online  environment  in  QUIP. 
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A master  or  primary  file  contains  data  elements  which 
aca  maintained  by  the  user  and  which  identify  records  in 
other  referenced  or  secondary  files.  These  data  eleaents 
are  ralLsl  pointers  and  consist  of  the  record  Key  (or 
minimally,  the  high-order  portion  thereof)  for  the  secondary 
files  and  may  also  include  a secondary  file  identifier.  In 
soie  cases,  the  record  Key  of  the  secondary  file  aay  be 
identical  to  the  record  key  of  the  primary  file  so  as  to 
allow  use  of  the  primary  file  key  as  the  pointer  element 
that  can  be  used  as  a pointer  to  a secondary  file.  Should 
the  interfile  relationships  be  complex,  the  pointer  may 
additionally  require  an  indicator  to  identify  the  secondary 
file  to  be  referenced.  This  is  accomplished  by  structuring 
the  pointer  as  a group.  The  first  field  contains  the  name 
of  the  secondary  file  or  a code  which  is  converted  to  the 
secondary  file  name  by  a subroutine  or  table  specified  in 
the  PFT ; and  the  second  field  contains  the  record  keys,  or 
high- order  portion,  of  the  referenced  records.  To  allow  the 
coiponants  to  recognize  this  group  as  the  special  type  of 
pointer  containing  the  file  identifier  and  record  Key,  it 
has  a standard  system  name  consisting  of  the  six  characters 
IF03PP  with  a suffix  which  is  a unique  (for  the  file)  letter 
or  digit.  Thus,  a maximum  of  36  such  pointers  is  possible 
for  any  file.  Finally,  defined  literals  and  sortKey  values 
(when  the  primary  file  is  a RASP  answer  set  or  retrieval- 
typ>  IF/SORT  statements  are  used  in  QUIP  query)  may  also  be 
used  as  pointers  to  seconds  ry  files. 

IFD  causes  processing  of  the  primary  file  record  to  be 
interrupted  and  a retrieval  made  from  a secondary  file  of 
one  or  more  data  records.  Those  records  are  then  processed 
against  the  logical  specifications  coded  for  the  secondary 
file.  After  processing  has  been  completed  for  those 
retrieved  secondary  file  records,  primary  file  processing  is 
resumed. 

The  selection  of  any  secondary  file  records  depends  on 
the  pointer  and  its  contents  at  the  time  the  primary  file 
processing  is  interrupted.  If  the  length  of  the  field  used 
as  the  pointer  is  equal  to  thB  length  of  the  record  Key  of 
the  secondary  file,  at  most  one  record  is  retrieved  from  the 
secondary  file  with  its  record  Key  matching  the  pointer.  If 
the  field  used  as  the  pointer  has  length  greater  than  the 
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length  of  the  record  key  of  the  secondary  file,  the  field  is 
truncated  before  retrieval  and  at  most  one  record  is 
retrieved  with  its  record  key  Hatching  the  truncated  field. 
If  the  length  of  the  pointer  field  is  less  than  the  length 
of  the  secondary  file  record  key,  the  retrieval  of  secondary 
file  records  consists  of  all  these  records  where  the  high- 
oriar  portion  of  the  record  key  Hatches  the  pointer,  the 
length  of  the  high-order  portion  being  deterained  by  the 
Length  of  the  pointer.  When  aore  than  one  record  is 
retrieved  in  this  nanner,  processing  of  the  secondary  file 
specifications  is  repeated  for  each  record. 


3.9  File  Analysis  and  Run  Optimization  Statistics 

The  Pile  Analysis  and  Run  Optimization  Statistics 
capability  provides  the  user  with  statistical  data 
concerning  the  activity  of  fields  in  the  data  file  and 
statistical  data  concerning  the  allocation  of  core  resources 
for  NIPS  360  PFS  production  runs. 


3.9.1  Pile  Analysis  Statistics 

The  File  Analysis  Statistics  involve  both  a stand-alone 
utility  to  count  data  file  field  references  of  all  of  a 
users  component  source  stateHents  and  conponent  execution 
statistics  showing  the  number  of  times  a source  statement 
was  executed.  Using  this  statistical  data  a user  may  aore 
afficiantly  determine  the  activity  of  the  data  file  fields. 

Statistics  for  file  analysis  are  gathered  by  the  user 
from  two  sources: 

o A NIPS  utility,  UTPLDSCN,  which  determines  which 
file  fields  are  referenced  in  each  source  RIT, 
retrieval,  and  logic  statement 

o i use  count  of  each  PIT,  retrieval,  and  logic 

statement  provided  by  each  NIPS  component. 

These  two  types  of  statistics  may  be  combined  in  a NIPS  file 
for  analysis. 
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Thi  stand-alone  utility,  IJTFLDSCN,  will  accept  as  input 
all  of  the  component  source  statements  for  a single  data 
file.  The  foreat  of  the  input  lay  be  cards  and/or  a or 
member  of  a partitioned  data  set  in  card  image  record 
foraat.  Priaary  input,  which  consists  of  control  cards  will 
be  a card.  Each  set  of  source  statements  must  be  preceded 
by  a control  card  to  identify  the  component,  module  name, 
ani  meaber  name.  The  format  of  the  card  will  be  as  follows: 


./  SOURCE  COHP=XXri,NAHE=SHAHE,  HEHBER=MNANE 
w her  e: 

./  must  be  in  columns  1 and  2 followed  by  one  or  more 
blanks. 


SOURCE  must  appear  as  shown. 

COR  P -X  XXX  where  xxxx  may  be  PH,  QOI P,  FASP  or  op. 

F AH  E=SN  A HE  where  SNAHE  is  the  name  of  the  source  module. 

H EH  BER  -=HFA  HE  where  MNAflE  indicates  that  the  source  is  a 
member  of  a partitioned  data  set  and  that  this  is  the 
member  name.  This  operand  must  be  omitted  if  the  source 
is  in  card  format.  Hired  formats  will  be  allowed. 

The  output  from  the  utility  will  consist  of  a listing  of 
the  source  statement,  followed  by  a listing  of  the  file 
fialds  with  a count  of  references.  After  all  source 
statements  have  been  processed,  a summary  listing  will  be 
provided  showing  the  count  of  data  file  field  references  by 
component.  A sequential  data  set  will  also  be  provided 
suitable  for  transaction  input  to  an  PH  run. 

The  utility  will  process  fields  in  the  source  statement 
from  a single  file  in  one  execution.  Hulti-file  RASP 
guaci.es  and  multi-file  PITs  will  be  accepted  as  input. 
However,  only  the  fields  fro*  the  input  data  file  will  be 
processed.  To  process  all  fields  from  all  files  referenced 
by  multi-file  queries  and  nulti-file  RITs,  it  would  be 
necassary  to  include  the  source  statement  in  a utility  run 
for  each  file. 
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Tha  batch  component  file  analysis  statistics  will  be 
initiated  dynamically  by  the  presence  of  an  entry  in  the 
catalog  far  a transaction  data  set.  The  data  set  name  must 
be  the  file  name  concatenated  with  a 'T*  suffix  and  must  be 
cataloged  to  the  same  voluae  as  the  data  file  or  a DD 
stateient.  naaed  TP.  ANST  included  as  an  additional  DD 
statement.  If  the  statistics  are  initiated  through  the 
catalog  entry  and  the  data  set  does  not  exist,  the  space  for 
tha  data  set  will  be  allocated  on  the  same  volume  as  the 
data  file.  If  the  additional  DD  is  included,  it  must  fully 
describe  the  data  set  according  to  JCL  requirements.  The 
disposition  for  the  transaction  data  set  will  be  MOD  so  that 
new  transactions  will  be  added  and  will  not  destroy  any 
transactions  gathered  previously. 

A parameter  PARN=NOSTAT,  may  be  entered  on  the  ET  EC  card 
to  override  the  gathering  of  the  statistics. 

Samples  of  the  transactions  output  by  the  file  analysis 
statistics,  with  a sample  PFT,  logic  statements,  query,  and 
NIT  utilizing  the  transaction  are  included  in  appendix  B. 


3.3.2  Run  Optimization  Statistics 

This  capability  produces,  on  user's  request,  statistical 
data  reflecting  the  core  allocation  during  maximum  core 
utilization  for  the  execution  of  the  component.  The 
breakdown  of  the  statistics  detail  the  amount  of  core  used 
for  user  subroutines  and  tables,  the  source  module  (PIT, 
query,  logic  statement),  processing  block  or  stash  area,  I/O 
buffers,  and  OS  access  method  subroutines.  The  information 
allows  the  user  on  subsequent  runs  to  specify  options  to 
make  more  efficient  use  of  his  core  allocation  by  specifying 
through  the  PARR  field  on  the  EXEC  card  the  core  required 
for  elements  such  as  process  block,  stash  area,  and  the  BLDL 
list.  The  amount  of  core  allocated  to  subroutines  and 
tables  is  indirectly  specified  by  adjusting  the  region  size. 
Tbs  core  allocation  for  I/t>  access  method  routines  remains 
constant  for  a given  run  and  may  not  be  overridden. 

This  capability  is  designed  primarily  for  use  with 
proi  uctron  runs  where  the  job  setup  remains  constant. 
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The  batch  components  FN,  RASP,  Op,  and  QUIP  recognize 
tha  Run  Optimization  parameters  in  the  PARK  field  of  the 
execute  card.  The  presence  or  absence  of  parameters  are 
int»rpr»ted  by  the  initialization  routines  to  determine 
processing  required  by  the  execution  phases  of  each 
component.  At  completion  of  »-he  execution  of  the  component, 
the  reporting  phase  outputs  all  gathered  statistical  data  as 
a printed  listing. 

Each  component  prints  a statistics  page  showing  core 
allocation  and  dynamic  resource  loading.  The  cote 

allocation  portion  indicates  the  processing  block  or  stash 
area  allocated  and  used,  the  amount  of  core  used  for  the 
source  modules  and  user  subroutines  and  tables,  and  the 
amount  of  core  used  for  I/O  buffers  and  access  methods.  The 
dynamic  resource  portion  of  the  statistics  includes  the 
number  of  tines  each  subroutine,  table,  or  logic  statement 
was  executed  and  how  many  times  it  was  rolled  out  of  core, 
he  reason  for  rolling  the  module,  either  insufficient  core 
r insufficient  BID  L list  fill  also  be  indicated. 

Th a user  may  alter  the  scheme  of  core  allocation  throuqh 
use  of  the  PARM  field  on  the  EXEC  card.  For  example,  if  all 
of  t.ha  stash  area  in  PASP  is  not  used  but  subroutines  or 
tables  referenced  on  the  SOFT  statement  are  rolled  due  to 
insufficient  core,  the  stash  area  may  be  decreased.  The 
excess  will  automatically  be  assigned  to  the  dynamic 
subroutine  area.  The  BL  DL  list  is  a list  maintained  by 
SUBSUP,  the  NIPS  Subroutine  Supertisor,  containing  the  name, 
siza,  and  disk  address  of  each  subroutine,  table,  or  logic 
statement  used.  Each  entry  in  the  list  requires  about  70 
bytas  of  core.  Ideally,  there  should  be  an  entry  in  the 
list  for  each  subroutine,  table,  table  page,  and  logic 

statement  executed  in  the  run,  and  there  should  be 

sufficient  core  so  that  no  modules  have  to  be  rolled  out. 

This  is  rarely  possible  in  batch  production  jobs.  The  user 
can  alter  the  length  of  the  list  to  use  core  most 

aff  icientl  y. 

The  Pun  Optimization  capability  will  be  initiated 
through  the  use  of  parameters  in  the  PARH  field  on  the  EXEC 
card  for  each  component.  The  parameters  and  their 

associated  functions  are  as  follows: 
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P os  - This  parameter  specifies  that  ran  optimization 
information  is  to  be  gathered  and  output. 

NOR OS  - This  parameter  omits  optimization  processing. 

If  no  other  parameters  are  used,  this  parameter 
need  not  be  coded,  as  it  is  the  default. 

The  parameters  to  be  used  to  supply  parameters  to  tailor 
-or»  allocation  ace  as  follows: 


TCP  = NK 


TCB^N 


TCS 


Indicates  the  number  of  bytes  requested 
for  processing  block  or  stash  area  in 
1000  ( K)  bytes. 

This  parameter  indicates  the  number  of 
entries  to  be  used  in  the  RLDL  list  for 
S'JBS  UP, 

This  parameter  indicates  that  the 
statistics  record  on  the  I SA  N data  file 
is  to  be  used  to  determine  the  process 
block  size.  This  parameter  should  not  be 
used  with  the  TCP  parameter. 


When  core  allocation  parameters  are  coded,  ROS  will  be 
performed  unless  the  NOHOS  is  coded  in  the  PARH  field  on  the 
execute  card. 


The  definitions  for  the  statistics  output  by  the  Run 
optimization  are  as  follows: 


CSte_flsase 

pegioa  size  - The  size  in  decimal  of  the  area  request- 
ed on  the  JOB  or  iZEC  card. 

Free  core  - The  amount  of  core  not  used.  This 

figure  will  not  include  fragments  of 
core  of  less  than  one  K. 


Access  methods  - Includes  the  area  allocated  to  the  access 

a e thods  . 
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buffers  - Aaount  of  cote  usad  foe  buffers  on  open 

dat  a sfits, 

Component  * Aaount  of  core  taken  up  by  the  batch 

coaponent  and  any  programs  loaded  by 
the  coaponent,  excluding  logic  state- 
aents,  PASP  queries,  and  PITS. 

Not*  : Core  sizes  are  given  in  bytes  (1024  bytes  = IK). 


Etai2.afi_ii.O£i/S\asli_i£gd_St.ati§^isfi 


Process  block 
size 


PM 


This  is  the  aaount  of  core  allo  cated  to 
the  process  block  or  st  Tea. 

Aaount  for  process  block 


PASP 


Aaount  allocated  to  stash  area. 


OP 


Hiniaua  aaount  to  contain  one  data  record 
and  associated  sets. 


QUIP 


Aeount  allocated  to  process  block. 


Aaount  used 


Aaount  of  process  block  or  stash  area 
used  for  storage  of  data  records. 


2 ufe  t a i UuaZIa  2i.se  ul  is.  a_  St  at  i-iti.  ta 

The  nuaber  of  entries  for  BLDL  lists  allocated  is  output 
with  the  nueber  of  entries  actually  used.  If  subroutines 
were  rolled  because  of  insufficient  BLDL  entries,  the  nuaber 
neossary  to  prevent  rolling  will  also  be  output.  The  user 
aay  then  on  the  next  run  specify  the  nuaber  required  to 
prevent  rolling  for  this  reason. 

The  aaount  of  corn  used  for  subroutines  and  tables  will 
be  listed  whether  or  not  they  were  added.  If  subroutines  or 
tables  were  rolled  for  lack  cf  core,  the  aaount  of  core 
listed  is  that  aaount  required  to  prevent  rolling.  The 
ut»r  eay  then  reduce  processing  block  or  stash  area  cize  to 
provide  aore  core  for  subroutines  and  tables,  if  feasible, 
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or  increase  his  region  size  to  prevent  rolling  tor  this 
reason. 

Poll  information  will  detail  tha  modules  that  were 
rolled  by  SUBSUP,  the  nuaber  of  tises  rolled,  and  the 
reasons  for  rolling. 


and 


If  the  run  is  an  Ffl  coaponent  execution,  the  subroutine 
table  statistics  will  also  include  logic  statements. 


3. ID  Xaproved  NIPS  File  Processing 

As  NIPS  is  used  in  an  e ve  r- wideni  ng  range  of 
applications,  data  file  usage  is  becoaing  aore  varied  and 
data  file  size  is  becoaing  larger.  The  following  three 
capabilities  provide  enhanced  file  processing  techniques. 


3.10.1  Qualified  Data  Set  Naaes 

Qualified  data  set  naaes  are  allowed  for  NIPS  data 
filss,  libraries  and  index  data  sets.  The  basic  name  aust 
confora  to  the  NIPS  naaing  conventions  (section  2.6.3),  To 
this  basic  naae,  additional  qualifiers  aa y be  prefixed  up  to 
a total  of  4«  characters.  Symbolic  parameters  and  data 
definition  (DD)  statement  overrides  must  specify  the  fully 
qualified  data  set  naae.  In  the  batch  node,  only  the  basic 
naae  (last  segment  of  tha  qualified  data  set  naae)  is 
specified  in  the  NIPS  coaponent  control  cards.  When 
comparison  is  required,  the  coaponent  addresses  only  the 
last  segment  of  the  gualified  data  set  naae  on  the 
appropriate  DD  statement.  In  online  applications  (QOIP,  PM, 
SDDfc,  EDIT,  VIEW  and  FOB HATTE F)  , NIPS  coaponents  utilize  the 
catalogue  to  locate  data  sets,  and  the  fully  qualified  data 
set  naae  must  be  specified. 


3.10.1.1  Specifying  a U3  er  Library 

A NIPS  user  can  specify  a library  by  use  of  selected 
data  definition  statements  in  the  NIPS  cataloged  procedures 
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which  include  the  SLIB,  TLIB  and  ELIB  DDNAHES.  The  library 
naie  Bay  be  a qualified  or  an  unqualified  data  set  naae. 

In  those  cases  wher?  the  DSNAHE  of  the  library  is 
iet»rain»d  by  suffixing  the  data  file  naae  with  an  " L" , the 
fully  qualified  naae  will  be  used.  If  this  naae  cannot  be 
locate!  in  the  catalog,  the  last  segaent  of  the  qualified 
data  set  naae  will  be  used  with  an  " L"  suffix.  If  a 
quilifiad  naae  is  not  used,  then  the  file  naae  will  be  the 
only  segaent. 


3.10.1.2  Specifying  an  Index  Data  Set 

A NIPS  user  can  specify  an  Index  Data  Set  by  use  of  the 
X.  IN D E7  PD  card.  The  DSNAHE  of  the  Index  Data  Set,  less  the 
suffix  "X",  Bust  be  the  s aa  e as  the  fully  qualified  data 
file  naae.  In  those  cases  where  the  DSNAHE  of  the  Index 
Da  ta  Sat  is  deternined  by  suffixing  the  ISAM  or  SAH  data 
base  naae  with  an  "X",  the  file  naae  used  will  be  the  fully 
qualified  data  set  naae.  If  a qualified  naae  is  not  used, 
then  the  file  naae  will  be  the  only  segaent. 


3.10.1.3  Data  Generation  Group 

Tha  PS  NAME  parameter  of  the  DD  cards  in  the  JCL  stream 
for  the  user  and  system  libarias  (SLIB),  sequential  data 
fil»s  (SAMPILE),  and  Index  Data  Set  (XDJDEX)  aay  be  a 
generation  data  set.  A generation  data  set  is  one  of  a 
collection  of  successive,  historically  related,  cataloged 
lata  sets  knowa  as  a generation  data  group.  To  create  or 
retrieve  a generation  data  set,  you  identify  the  generation 
data  group  naae  in  the  DSNAHE  parameter  and  follow  the  group 
naae  with  a relative  or  absolute  generation  nuaber. 

A generation  data  group  can  consist  of  cataloged 
sequential,  partitioned,  indexed  sequential  (if  the  data  set 
is  defined  on  one  DD  stateaent)  , and  direct  data  sets 
residing  on  tape  voluaes  or  direct  access  voluaes.  A NIPS 
ISAM  data  file  would  noraally  not  be  part  of  a generation 
data  group  since  the  data  set  is  defined  using  three  DD 
stateaents  * 
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3.10.2  Cataloged  Procedures  and  Pile  Block  Size 

Considerations 

All  NIPS  360/FPS  cataloged  procedures,  components  and 
utility  prograas  are  designed  to  process  files  with  a block 
size  of  1,004  bytes  or  greater.  The  standard  file  block 

size  is  1,004,  but  the  block  size  of  any  file  can  be  set  by 

the  user  to  a size  of  1 ,004  or  greater  as  long  as  the 
spacified  size  does  not  conflict  with  S/360/OS  Data 
■tanageaent  rules  or  storage  device  limitations. 

If  a user  elects  to  change  the  block  size  of  a file,  he 
can  do  so  with  any  cataloged  procedure  that  generates  a file 
or  produces  a new  copy.  These  procedures  are  easily 

recognized  because  they  include  the  symbolic  parameter 
BSZNEWP,  which  allows  the  user  to  specify  the  block  size  of 
th?  new  file. 

Once  a file's  block  size  is  changed,  the  file  will 
retain  that  block  size  until  changed  again  by  the  user. 

Block  size  specifications  or  the  use  of  symbolic 

parameters,  BSZFILE  or  BSZNEWP  are  always  required  for  the 
following  conditions: 

1.  BSZNEWP  iust  be  used  to  change  a file's  block 
size, 

2.  BSZNEWP  must  be  used  to  generate  a file  with 

a block  size  greater  than  1 ,004. 

3.  BSZFILE  must  be  used  when  processing  a non- 

standard block  size  file  residing  op.  unlabeled 
tape. 

The  effects  of  increasing  a file's  bloc*  size  are: 

1.  Less  storage  space  required  because  of  fewer 
inter-record  gaps 

2.  Less  I/O  time  required  during  processing 

3.  More  core  required  during  processing. 
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The  BSZNEHF  parameter  cannot  be  used  to  modify  the  block 
size  of  an  output  VSAH  file.  The  block  size  of  the  VSAH 
fils  lust  be  set  when  the  file  is  defined  by  the  VSAH 
service  routine  IDCAHS  as  set  forth  in  Volute  VIII  - Job 
Preparation.  When  going  from  VSAH  to  SAN  the  block  size  of 
the  SAN  file  will  be  1004  unless  overridden  using  the 
BSZNEWP  parameter. 


1.10.3  Compression  and  Compaction  of  Data  Records 

Compression  and  compaction  provide  a means  for  the 
reduction  of  intermediate  storage  requirements  for  data 
without  altering  the  integrity  of  the  data.  This  data 
reduction  scheme  is  particularly  suited  to  data  files  that 
contain  strings  of  identical  characters  or  a large  quantity 
of  alphabetic  data. 

A string  of  identical  characters  is  compressed  by 
translating  it  to  two  bytes.  The  first  byte  is  a control 
byte  which  indicates  that  compression  has  been  applied  and 
gives  a count  of  the  number  of  identical  consecutive  bytes 
that  ware  in  the  original  string.  The  second  byte  is 
identical  to  those  in  the  original  string. 

A striny  of  alphabetic  characters  Is  compacted  by 
translating  it  to  a control  byte  followed  by  a string  of 
coded  characters.  The  control  byte  indicates  that 
compaction  has  been  applied  and  gives  a count  of  the  coded 
characters.  Each  coded  character  represents  a combination 
of  two  adjacent  alphabetic  characters. 

Compression  or  compaction  can  be  applied  to  data  files 
by  specifying  COHPPESS  or  COHPACT  respectively  for  the  PAFM 
on  the  EXEC  card  of  the  SAN  to  ISAN/VSAH  and  ISAH/VSAN  to 
SAl  utilities.  A combination  of  both  can  be  specified  by 
including  both  keywords  in  the  PARN  list.  If  both  are 
specified,  compression  is  applied  to  a record  first  and  data 
within  the  record  that  cannot  be  compressed  is  operated  upon 
by  the  compaction  routine. 

The  compression  and/or  compaction  process  can  be 
reversed  by  specifying  EXPAND  for  the  PARK  on  the  EXEC  card 
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for  either  utility.  All  components  process  compressed 
mi/or  coipacted  files  tc  ansparently  to  the  user. 


3.11  Subfile  Capability 

The  subfile  capability  allows  the  user  to  define 
increasingly  discrete  queries  so  that  each  new  query 
processes  a decreasing  number  of  data  records  of  the  file. 
Th3  capability  is  available  in  the  QUIP  component  in  the 
online  environment. 

The  subfile  capability  is  accomplished  by  allowing  the 
user  to  create  a subfile  consisting  of  selected  entries  from 
the  file,  the  entries  being  selected  based  on  the 
conditional  expressions  in  the  query.  Subsequent  queries 
are  automatically  directed  against  the  subfile  until  the 
user  creates  a lover  level  subfile  or  explicit/  specifies  a 
different  source  of  input. 

Subfile  processing  i3  initiated  by  the  user  when  he 
includes  the  SUBFILE  operator  in  a QUIP  query  in  the  online 
environment.  The  first  use  of  the  operator  causes  the 
naming  and  allocation  of  a partitioned  data  set  on  a direct 
access  system  work  volume.  Each  subfile  request  results  in 
creation  of  a new  member  of  the  partitioned  data  set. 

The  name  of  the  subfile  partitioned  data  set  is 
internally  generated  by  forming  a qualified  data  set  name  of 
two  levels:  the  first  is  the  terminal  identification  as 
defined  at  NIPS  TP  Monitor  system  generation  and  the  second 
is  tha  internal  computer  time  of  the  query  at  the  time  the 
data  set  is  allocated.  This  name  is  displayed  at  the 
terminal  when  it  is  allocated  and  may  be  used  later  for 
identification  to  access  the  subfiles  should  a system 
failure  occur  which  causes  a checkpoint  restart  of  NIPS  TP 
to  occur. 

The  subfile  partitioned  data  set  is  deleted  when  the 
usar  signs  off  from  QUIP.  However,  the  existing  subfiles 
for  a partition  file  are  made  unavailable  when  a query  is 
diractad  against  another  NIPS  EPS  data  file. 
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A subfile  consists  of  the  record  Keys  of  the  qualifying 
records  for  the  query,  rather  than  the  entire  record, 
thereby  reducing  I/O  time  and  space  requirements  for 
processing  subfiles.  When  a query  is  directed  against  a 
subfile,  the  record  keys  in  that  subfile  are  exaained  to 
determine  which  cecocds  in  the  aaster  file  are  to  be 
accessed.  If  a query  directed  against  a subfile  contains  a 
retrieval  which  operates  in  the  Candida te-access  aode,  the 
candidate  list  built  by  Index  Processing  is  used  to  further 
restrict  the  access  of  waster  file  records  to  those  subfile 
entries  which  are  also  candidates  froa  Index  Processing. 

The  subfile  capability  allows  the  user  to  create  a 
subfile  and  an  output  display  si  aulataneo  usl  y so  that  the 
data  for  entries  in  the  subfile  way  be  exaained  while  the 
subfile  is  being  created. 

There  are  no  restrictions  on  the  number  of  subfile 
levals  the  user  is  able  to  create.  Any  existing  subfile  for 
the  current  aaster  file  way  be  referenced  as  an  input  source 
so  that  interrogations  may  be  performed  froa  that  level. 

Subfiles  generated  at  one  terminal  are  available  for 
interrogation  at  other  terminals  in  the  system.  The  user  is 
required  to  refer  to  the  subfile  name  in  his  guery  for 
access  to  the  subfile. 

The  subfile  capacility  includes  a trace  function  which 
permits  a user  to  display  part  or  all  of  the  contents  of  the 
subfile  partitioned  data  set.  This  function  allows  the  user 
to  review  all  subfiles  created  from  the  same  (current)  data 
f ile. 


3.12  Non-NIPS  Quecy  Capability 

NIPS  can  also  be  used  to  retrieve  and  output  data  froa 
data  files  that  were  created  either  by  other  data  aanageaent 
systeas  or  by  special  purpose  programs.  This  capability  is 
available  through  QUIP  in  both  the  batch  and  online 
envi  consents. 
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To  perfor*  non-NIPS  processing,  the  user  aust  first 
create  a pseudo-PPT  which  describes  the  data  file.  Creation 
of  the  pseudo-PPT  is  by  PS  through  the  standard  PS  language 
plus  one  non-NIPS  control  stateaent  and  several  non-NIPS 
operands.  After  the  pseudo-PPT  has  been  structured  and 
stored  as  an  ISAM  data  set,  QUIP  can  be  used  to  query  the 
non-NIPS  data  file.  All  of  the  standard  QUIP  processing 
techniques  can  be  applied  to  a non-NIPS  file  with  the 
exception  of  index  processing.  Care  Bust  also  be  taken  when 
attempting  to  process  numeric  or  coordinate  data  fields  as 
there  is  no  NIPS  check  for  valid  contents  of  these  fields. 

Files  which  are  to  be  processed  via  the  non-NIPS  query 
capability  iust  conform  to  the  following  general 
restr  ictions: 

1.  The  file  can  be  either  a SAN  or  an  ISAM  data  set. 
Records  in  the  file  can  be  either  fixed  length  (up 
to  996  bytes)  or  variable  length  (up  to  1000 
bytes),  and  either  blocked  or  unblocked. 

2.  Each  record  aust  contain  record  identification  data 
which  is  contained  in  one  or  more  user  designated 
fields.  These  fields  need  not  be  contiguous;  but 
■ ust  be  present  in  each  record.  The  location  of 
these  fields  aay  differ  for  differing  record 
formats  but  the  size  of  the  fields  and  their 
celative  position  within  the  total  record  ID  aust 
renain  constant.  The  total  length  of  the  ID  oust 
not  exceed  256  bytes. 

3.  All  records  with  a coaion  record  ID  aust  be 
physically  together  in  the  file  and  the  file  aust 
be  in  ascending  sort  sequence  as  specified  by  the 
record  ID. 

4.  Each  record  aust  contain  a single  data  eleaent  of 
up  to  10  bytes  in  length  which  can  serve  as  a 
record  type  field  to  uniquely  identify  each  record 
foraat.  The  location  and  length  of  the  record  type 
field  aust  teaain  the  saae  for  all  records.  A 
aaxiaua  of  256  different  record  types  aay  be 
i denti  fied. 
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5.  One  record  type  Must  be  identified  as  a non- 
repeating format  to  serve  as  a fixed  set.  This 

forest  must  occur  once  (and  only  once)  for  each 

group  of  records  having  a coiiod  record  ID.  A 11 
other  record  types  are  considered  to  be  repeating, 
and  their  presence  is  optional. 

S.  Numeric  data  for  which  arithmetic  computations  are 

to  be  perforaed  must  be  defined  in  either  binary  or 
zoned  decimal  (EBCDIC)  format.  Ml  other  numeric 
data  fields  (non-f ullword  binary,  packed  decimal, 
and  floating  point)  must  be  treated  as  alphabetic 
data  and  a user-written  subroutine  must  be  supplied 
for  output  conversion.  Binary  format  requires  that 
the  data  be  contained  in  a fullvord  on  a fullword 
boundary. 

7.  coordinate  data  must  be  stored  in  a.  fullword  for 
aach  longitude  and  latitude  and  must  conform  to  the 
standard  NIPS  binary  representation. 

B.  Variable  length  data  fields  are  permitted  provided 
only  one  variable  field  is  defined  for  a record 
type  and  it  is  the  last  field  in  the  format.  Also, 
the  format  must  contain  a fullword  binary  field 
which  will  contain  the  length  of  the  variable 
f iel  d. 
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SECTION  4 

SAMPLE  NIPS  360  PPS  CATA  PILE 


This  section  introduces  a sample  data 
typical  for  the  files  handled  by  the 
presented  here  since  the  Users  Manuals  for 
will  use  examples  pertaining  to  this  file. 


file  which  is 
system.  It  is 
all  components 


4.1  General  Pile  Organization 

The  name  of  the  sample  file  is  TEST3S0.  Its  structure 
is  defined  to  contain  information  concerning  the  status, 
organization,  location,  and  equipment  of  combat  units  of  the 
araed  forces.  Each  data  record  in  the  file  defines  a single 
unit  in  the  armed  forces.  Hence,  the  key  to  each  record 
will  be  the  unit's  identification  code.  Data  in  each  record 
has  been  formatted  into  a fixed  set,  six  periodic  sets,  and 
a variabla  set.  Data  conversion  subroutines  and  tables  have 
been  defined  to  process  some  of  the  record's  data. 

The  logical  breakdown  of  data  in  a record  is  discussed 
below. 

FIXED  SET  - The  fixed  set  contains  data  defining  the 

attributes  of  the  unit  which  need  only 
one  data  value  for  satisfaction.  Examples 
of  this  ace  the  unit's  location,  status, 
activity,  and  commander's  name. 

periodic  Sets  - The  six  periodic  sets  are  used  to  contain 

information  defining  the  unit  whose 
record  elements  may  have  more  than  one 
data  value.  Por  a periodic  set,  each 
collection  of  data  having  the  same  format 
is  called  a subset  of  the  periodic  set. 
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PERIODIC  SET  1 - Each  subset  contains  data  describing  a 

piece  of  major  equipment  or  a weapon 
type  possessed  by  the  unit. 

PERIODIC  SET  2 - Each  subset  contains  data  describing 

a piece  of  secondary  equipment  or  non- 
essential  material  not  required  for 
the  unit*s  operation. 

PERIODIC  SET  3 - Each  subset  contains  data  describing 

an  operation  plan  which  the  unit  Bust 
follow . 

PERIODIC  SET  4 - Each  subset  contains  the  name  of  a treaty 

to  which  the  unit  is  responsible. 

PERIODIC  SET  5 - Each  subset  contains  information  on  a 

senior  or  staff  officer  of  the  unit. 

PERIODIC  SET  6 - Each  subset  lists  a subordinate  unit 

reporting  to  the  unit. 

VARIABLE  SET  - The  variable  set  in  each  record  contains 

coBBentary  information  about  the  unit. 


4.2  Record  ELement  Description 

This  section  describes  each  element  in  the  file's  record 
fore  at.  The  source  language  statements  used  to  define  the 
format  of  this  file  appear  in  the  File  Structuring  volume  of 
the  NIPS  3 60  TPS  Users  Hanual. 
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Elsient  Element  Set  Input  Output 


Ui.it 

_Ll£« — Jilt- 

h 

Node 

SER  V 

Record  Fixed 
Control 

Fi  el  d 

1 

ALPHA 

UUIH 

Record  Fixed 
Control 

Fi  el  d 

5 

ALPH  A 

'JIC 

Record  Fixed 
Control 

Group 

6 

ALPH  A 

UNTYY 

Field 

P ixed 

4 

ALPHA 

UNT  Y 2 

PL  eld 

Fix  ed 

1 

ALPHA 

UNL  VL 

Field 

F ixed 

3 

ALPHA 

UNTLY 

Group 

Pixed 

8 

ALPHA 

HOlE 

Field 

F ixed 

1 

ALPHA 

UN  FL  G 

Field 

F ixed 

1 

ALPH  A 

1JF3  F 

Field 

F ixed 

1 

ALPH  A 

PREY 

Field 

Fix  ed 

ALPHA 

Conv. 

R eaar  Ks 

RCHDS 

GCHDS 

Service  Branch 

Co  de 

Un it  Ident  if  ier 
(Service) 

Unit  Identification 
Code  (Fields  - 
SEPV,  GUIN) 

Military  Unit 

Type  Code 

Major  unit 

Ind icat  or 

UNLVS 

Unit  Organization 
Level 

Unit  Type  and  levni 
(Fields-  UNTYY, 

U NT  YE , UNLVL) 

RCNDS 

OCMDS 

Current  Home 

Command 

Unit  Flag  - 
Reserved  tor 

Specia 1 Use 

Major  Focce 
Indicator 

RCNDS 

OCMDS 

Previous  Hone 

Coaaand 
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E1»«p  r.t 
HUl 

Element 
..LXfit 

Set 

JSii 

LS0.SU 

Input 

Out  put 

££nvA_ 

EeaacKs 

ATACH 

Field 

Pixed 

1 

ALPHA  BCNDS 

OCHDS 

Attached  Coaeand 
Reporting  Units  Statu 

FOTU 

Pi  eld 

Fix  ed 

1 

ALPHA  RCHDS 

OCHDS 

Future  Hoae  Coaaanl 

TROT'S 

neld 

Pixed 

10 

ALPHA  DTGIS 

DTGOS 

Transfer  Date  to 

New  Coaaand 

UNRDY 

Pi.  eld 

Pix  ed 

2 

ALPHA 

Readiness  Status 

REAS  N 

Field 

Fixed 

1 

ALPHA 

Readiness  Down- 
grade Reason 

ft  ATT  N 

Pi  eld 

Fix  ed 

2 

ALPHA 

Readiness  Expert?! 
to  Attain 

P ECO  F 

G coup 

P ixad 

5 

ALPH  A 

Unit  Readiness 

Status  (Fields- 
UNRDY,  RKA3  N,  P.ATTN) 

? adi  i; 

Pi  eld 

? xx  ed 

10 

ALPHA  DTGIS 

DTGOS 

Attainable  Readi- 
ness Status  Date 
an  d T i a e 

UNIT 

Field 

Fixed 

12 

ALPHA 

Short  Unit  Naae 

UNAKE 

Fi  el  d 

Fix  ed 

27 

ALPHA 

Full  Un it  Na  ae 

o?  co  x 

Field 

f i x ed 

6 

ALPHA 

UIC  of  Higher 

Unit  Having 
Operational  Control 

oirjp 

Pield 

P i.  x ed 

20 

ALPH  A 

C.O.  Naae  and  Rank 

L0C 

Field 

F ixed 

18 

ALPHA 

Location  or  Hull 
Nueher  of  Unit 

PDI*  T 

Field 

? ixed 

11 

COORD 

Geographic  Location 

(Lat-Long)  of  Units 
Headguarters 
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Els  aent 

El  e«ent 

Set 

Input 

Output 

HilS. 

_I  JLES. 

Mi. 

Length 

no<}§_  Copy . 

COQ»i_ 

Reaarks 

DAPTI 

PL  el  d 

Fix  ed 

11 

COO  R C 

^ Geographic  Points 

! 

(Lat-Long)  Defined 
in  Counterclock- 

0APT2 

Field 

Fix  ed 

U 

COOP  c 

i 

wise  Order  Nnic'n 
Defines  the  Unit ' s 
Area  of  Deployment. 

DAPT  1 

Pi  eld 

F ixed 

11 

COORD 

or  responsibility 

DAPTU 

FL  el  d 

Fix  ed 

11 

COORD 

AREA 

Group 

Fired 

ua 

COORD 

Coordinate  Ares 
(Fields-DAPTl, 
DAPT2,  DAPT  1, 

DAP  TU) 

CNTR  r 

Field 

F ir  ed 

2 

A I. PH  A 

CT  RTS 

Country  Code 

Where  Unit,  is 
lo  cat  ed 

CNAK 

Field 

Fired 

15 

ALPHA 

Country  Name  Where 
Unit  is  Loci  ted 

GEPOL 

Field 

Fixed 

2 

ALPH  A 

CTPYS 

Geopolit  ical 

Code  Where  Unit  is 

Loca  ted 

P EX  5 

Field 

F ixed 

6 

NUNEP 

Aut  hor ized 
Personnel  Strength 

ACTI  V 

Field 

Fix  ed 

2 

ALPHA 

ACTV5 

Current  Activity 

Co  de 

LAUD 

Field 

F ixed 

10 

ALPH  A 

Date-Tine  of  Last 
Reco  rd  Updat  e 
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Eleit-nt 

nut.. 

Eleeent 

.LXfit— 

Set 

k*u<lU> 

Usds. 

Input 

Sabi* 

Out  pu  t 

£2BXx_ 

ESI&tlS 

LYB 

Pi  eld 

Fixed 

l 

AI.  P H A 

Location  Status 
Whether  Known, 
Unknown,  or 

Eabar  k«d 

NPP.Rr, 

Field 

Fixed 

l 

NUN  KB 

Personnel  Readi- 
ness Code 

H EilP  T 

Pi  eld 

Fixed 

l 

NtINF  F 

Equipment  Readi- 
ness Code 

RT  RNG 

Field 

Fix  ad 

1 

NUN  SR 

Training  Reidi- 
ness  Code 

FNGRP 

Group 

F ixed 

u 

NUHER 

Readiness  Group 
(Fi  el  ds-RPERS, 
RSPLY,  FE3PT, 

RTRNG) 

READAVG 

Field 

Fix  ed 

3 

NUN  ER 

Readiness  Aternq* 
to  Hundredths 

NTTNN 

field 

Fixed 

3 

NUNER 

f s of  Naxiuua 

D . .nee  fro* 

Co  a a an  d Ship  - t o 
Tenth  . Na ut . Niles 

UNI  VI' 

field 

F ix  ad 

ALPH  A 

Unit  Type  Code 

TPM  AM 

Field 

Fixed 

42 

ALPII  A 

Unit  Type  Naee 

untqf; 

Field 

Yi  xed 

17 

ALPHA 

T/O  end  E 

P ef erence 

H I BN 

Pi  eld 

F lxed 

11 

AL.Pi:  A 

Uft  i*  llier  at  chy 

Cod  a 
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Element  Eleaent  Set  Input  Output 

jlaoe _Iir§ N.2j. L®S2lli  Wo3 e Con v.  (^o n v. Rea  arks 


cons  ENT 

Field 

F ixed 

Varis  ble 

Variable  Length 
Field  to  H old 
Coeeents 

MECL 

Field 

1 

3 

ALPHA 

Major  Equipaent 
Class 

m EQPT 

Field 

1 

10 

ALPH  A 

Major  Equipment  ID 

M ECL? 

Subset 

Control 

Group 

1 

13 

ALPH  A 

Major  Equipment 
Class  and  Type 
(Fields  - MECL, 
ME2nT) 

memod 

P i eld 

1 

10 

ALPHA 

Ha  j,  • gu  ip  me  nt 
Model  Nu«b«c 

ME  NAM 

Field 

1 

16 

ALPHA 

Major  Equipment 

Nane 

1 ECAP 

Field 

1 

1 

ALPH  A 

Weapon  Delivery 
Capability  Code 

MEPST' 

Pi  el  d 

1 

3 

NIJH  ER 

Number  of  F.  g u a p- 
aents  Possessed 

MEADA 

field 

1 

3 

NUMF.R 

Wuaber  of  Equip- 
ments on  A 1- rt 

YD  PC 

Field 

1 

3 

NUMER 

Nu»  ber  of  uip- 

aenta  Ready  for 
Conventions  1 

Weapon  Deli  very 

MEOP  N 

field 

1 

3 

NIJM  FR 

Wuaber  of  Equip- 
ments Peniy  foi 

Hue  la  at  Weapon 

Del i vut  y 
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Element 
Eili 

El  er  ent 

Set 

Jt£Q3ti} 

Input 

£2111* 

Output 

£2SS*_ 

Reuse  ks 

* 

flESQP 

Field 

l 

3 

N'JHER 

Number  of  Equip- 
ments on  Special 

Alert 

! 

i 

1 ESHP 

Field 

l 

3 

NO  HE  R 

Number  of  Equip- 
ments on  Special 

Alert  with 

Nuclear  Capability 

i 

HESIA 

Group 

l 

6 

NUflER 

Special  Alert 

Group  (Fields  - 
RES  QP,  RES i P) 

1ESIC 

Pield 

l 

3 

NUHER 

Number  of  Equip- 
ments Committed 
for  Special  Alert  a 

REREC 

Pield 

l 

10 

ALPHA 

Equipment 

Reconna  isss  nee 
Capability 

HEDEP 

Field 

l 

1 

ALPHA 

Code  indicating 
if  Equipment  is 
at  Home  Locution 
or  TDK 

1 EDDT 

Field 

l 

5 

NUHER 

Date  Equipment 
wen  t tn  TDK  Statj; 
(Julian  Date) 

NEDUP 

Field 

i 

1 

ALPHA 

TDlf  Duration  Code 

« EL  T r 

Field 

l 

1 

ALPK  A 

TDY  Deploynent 

Sta  tua 
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Element 
N a§e 

KEIOC 

El e« ent 
_I»S— 

Fl  eld 

Set 

g.0, Lea  at  b. 

1 18 

Input 

N°ie—  Coa£i- 

ALPH  A 

Output 

He®  arks 

TDY  Equipment 
Location 

n spy  t 

Pield 

1 

11 

COQFD 

Geographic  Location 
(Lat-Long)  of  TO* 

Equipment 

« Eift  y 

Fi  eld 

1 

2 

ALPH  A 

CTRYS 

Country  Code  whece 
TOY  Equipment  is 
Located 

MEP1L 

Pield 

1 

2 

ALPH  A 

CTRYS 

Geopolitical  Area 
Code  where  TDY 
Equipment  is 

Locat  ed 

MF.CN  A 

Pield 

1 

15 

ALPHA 

Country  Name  f ot 
TOY  Location 

SECLASS  Pield 

2 

3 

ALPHA 

Secondary  Equipmer 
Classi f icat ion 

SEHODEL 

Pield 

2 

10 

ALPHA 

Secondary  Equipment 
Model  Number 

3 A H E 

Field 

2 

10 

ALPH  A 

Secondary  Equipment 
Popular  Name 

SEPOS5D 

Pield 

2 

4 

HUH  EF 

Number  of  Equip* 
men  ts  Posse seed 

SEA  UT  H 

Field 

2 

4 

NUfiEF 

Number  of  Equip- 
ments Authorized 

Pi  AN 

Field 

3 

4 

NUN  F0 

Plan  Identification 

Number 
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Llaient 
H4.»e 

EL  eaent 

Set 

Hat— 

Input 

isaatfc  S2flvx 

Output 

asiasis  

PLEAC 

Fi  eld 

3 

i 

ALPHA 

Plan  Status  Cod? 
for  Unit 

PLDTG 

Field 

3 

10 

ALPHA  DFGIS 

DTGOS 

Date-Tine  Unit 
Adhered  to  Plan 

PLPST 

Field 

3 

1 

ALPHA 

Expected  Plan 

Status  Code 

PLFDG 

Field 

3 

10 

ALPHA  DTGIS 

DTGOS 

Expect  Date-Tiae 
Unit  will  be 
Coaaitted  to  Plin 

PLRT 

Field 

3 

6 

ALPHA 

Plan  Response  Tiae 

PLTRT 

Field 

3 

6 

ALPHA 

Transportat ion 
Staging  Tiae 

TPTY 

Field 

4 

6 

ALPH  A 

Treaty  Code  of  Unit 
Affiliation 

N AN  F 

Field 

5 

18 

ALPHA 

Senior  Officer /PO 
N&ne 

RANK 

Find 

5 

U 

ALPHA 

Senior  Officer/PO 
Rank 

SERNUHfi 

Pield 

t, 

6 

ALPH  A 

Serial  Nuabar 

SERVICE 

Field 

5 

1 

ALPHA 

Service  Branch  Code 

ASS3N 

Field 

5 

20 

ALPHA 

Unit  Aseignaent 

SPCODE 

Field 

5 

5 

ALPHA 

Specialty  code 

SBUIC 

Pield 

b 

6 

ALPH  A 

Subordinate  Unit  UI 
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Element  Elenent  Set 
t!2e__ 


In  put 

4 qn  gt  h H od  e_  Cgrjv4 


Output 

Con v^_  Re war ks 


SBFLG  Field  6 


6 ALPHA 


Reason  for 
Subordinate  UIC 


LEPER  Variable 
Set 


Unit  Reaarks/ 
CoBBents  in 
Unformatted  Form 


4.3  Subroutine/Table  Description 

This  subsection  describes  the  conversion  subroutines  and 
tables  used  by  the  saaple  file. 


4.3.1  Table  - RC  HD S 

The  table  flCMDS  is  used  for  input  data  conversion.  It 
wiLl  accept  up  to  a 6-character  argument  and  produce  a 
single  character  rode  as  a function.  The  table  is  used  for 
converting  nanes  of  unified/specified  coiiands  to  single- 


charactar  codes,  k saaple  of 

USCG 
USAG 
US  HC 
4CS 


NOPAD 
S AC 


4.3. 2 Table  - DC  HD 5 

The  table  SfiflCS  is  uaert 
accepts  a single-character 
specified  cosaarid  and  expands 


he  table  contents  follows; 

EU1SX12K 

E 

J 

H 

U 


3 

8 


for  output  conversion.  It 
code  representing  a unified/ 
it  to  a naee  of  tv  to  six 
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characters.  The  table  is  used  with  the  input  conversion 
table,  3CNDS.  A sample  of  the  table  contents  follows: 

ABGHgiNT  gUgCTiON 

H NARINE 

N NAVY 

R RCAF 


« 

2 

4 

7 


• 

AN4AC 
LA  NT 
EUCDN 
STRIKE 


4 .3.3  Table  - Cl  RYS 


The  table  £tm 
accepts  as  an  arg 
country  or  geopolit 
charactars  in  Len 
follows: 


is  used 

iment  a 2- 
ical  a rea 
gt  h.  A 


for  output  conversion.  It 
character  code  and  expands  to  a 
name  which  say  bn  up  to  15 
saeple  of  the  table  contents 


msiu im 


AC 

AL 

AT 

BD 

C3 

EG 

CU 


ATLANTIC  DCF  AN 

ALBANI A 

AUSTRALIA 

BERHUDA  ISLANDS 

CAMBODIA 

EGYPT 

GUAM 


• 

TH 

19 

37 

47 

65 


THAILAND 
LOUISIANA 
OK  LA  FOMA 
VIRGINIA 
PACIFIC  ISLANDS 


HI 
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4.3.4  Table  - ACTVS 


The  table  ACTVS  is  used  for  output  conversion.  It 
accepts  a 2-character  code  and  expands  it  to  state  a certain 
military  activity  of  up  to  15  characters.  A sample  of  the 
table  contents  follows: 


ruKiio.fi 


AC 

CD 

CO 

DE 

El 

n a 


ACTIVATING 
CIVIL  DISTURB 
COMBAT 

DEACTIVATING 
EXEB/MANEUVEP 
MAI  NTENANCE 


• 

SF 
S R 
TR 


SHOW  OP  PORCE 
SEARCH/RESCUE 
THAI NI NG 


4.3.5  Table  - UNLVS 


Tha  table  UfiLI5  is  used  for  output  conversion-  It 
scripts  up  to  a 3-character  code  and  expands  it  to  state  a 
unit's  level  using  up  to  15  characters.  A saaple  of  the 
table  contents  follows: 


ACD 

ANX 

CO 

DA? 

PLT 

hq 

HSP 

MSB 

PLT 

RCT 


ACADEMY 

ANNEX 

COMPANY 

DIV  AP  TILLERY 

NUMBERED  FLEET 

HEADQUARTER  S 

HOSPITAL 

MERCHANT  SHIP 

PLATOON 

RGT  OHBAT  TEAM 
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4.3  ,b 


SYD 

TF 

OSS 


Subroutine  - DTGI5 


SKIP  YARD 
TASK  PORCE 
OS  SHIP 


The  subroutine  DTgXS  U3®d  for  input  data 
accepts  a 12- character  lata  itea  which  is 


It 

group  and  converts  it  to  a 
sorting  dates  in  sequence. 


conversion . 
a Date- Tiae 


10-cha  racter  fora  suitable  for 


The  input  foraa  t to  the  subroutine  is: 

DDTTTT&MHHYY 

w here 

DD  ® Day  of  Honth 

TTTT  - 2400  Hour  Tiae 

9 * Plag  Indicating  Greenwich  Tiae 

HUM  " Honth  (Jan,  Feb,  ---  Dec) 

YY  * Year  (65,  66  ) . 

Tha  output  foraat  froa  the  subroutine  is: 

YYHHDDTTTT 


wh  • re 


4.3.7 


Subroutine  - 


The  subroutine 
accepts  as  input, 
by  DTGX5  and  converts 


YY 

m 

Yea  r 

(65, 

66  ---) 

HH 

a 

Honth 

Code  (Jan*01, 

DD 

m 

Day  of  Honth 

TTTT 

» 

Gres  nvich 

Tiat . 

- DT 

G0*> 

DT  GOS 

is 

use  d 

for 

output  CO 

the  ' 

0-- 

h»  r» z 

te  r 

Da  tt  'Tias 

Feb"02) 


it  to  the  12-chacacter 


Gro  up 

source 


Lon.  It 
pro  duced 
t ora*  t. 
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4.3.8  Table  - KEYSTOP 


Tha  table  KEYSTOP  is  used  as  a STDPMORD  table  in 
connection  with  KEYWORD  processing  of  the  index  file  for 
TEST360  file.  STOPWORD  tables  are  generated  and  updated  by 
tha  UTNDYKHD  utility  and  contain  a list  of  words  that  are  to 
be  eliminated  fros  keyword  processing.  A sample  of  the 
table  contents  follows: 


A 

AND 

AS 

BUT 

POR 

THE 

THERE 

THIS 


4.  3.  9 Table  - ACCEPT 


Tha  table  ACCEPT  is  used  as  a DICTIONARY 
connection  with  Keyword  processing  of  the  ind 
TEST360 . DICTIONARY  tables  are  generated  and  upd 
UTH  Dy  KN  D utility  and  contain  a list  of  all 
keywords  that  nay  appear  in  the  index  file.  A sa 
table  contents  follows: 


table  in 
ex  file  for 
ated  by  the 
allowable 
■pie  of  the 


BATTALION 

DIVISION 

HANUEVEFS 

STRATEGIC 

TRAINING 

TRANSPORT 

WEAPONS 
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Soction  5 

GLOSSARY 


This  section  contains  a list  of  tens  coaaonly  used  with 
the  NIPS  360  FFS.  A brief  description  is  supplied.  Host  of 
th2  tens  the  user  say  come  across  which  are  related  to 
S/360  hardware  and  standard  software  are  not  repeated  here 
since  they  are  adequately  discussed  in  the  XBN  SQL 
publ ications. 

Block  1.  A physical  record  (separated  froa  other 

records  by  inter-record  gaps)  which 
contains  Multiple,  logical  data  records. 
Refer  to  blocking  of  records. 


Block  Count 
(Field) 


Blocking  of 
R9c  oris 


Circle  Search 


cob  poamt 


2.  A group  of  conputer  words  considered 
as  a unit  by  virtue  of  their  being 
stored  in  successive  storage  locations. 


A field  which  is  the  first  fou 
of  each  block  of  file  records, 
the  nuiber  of  characters  in  th 
not  confuse  with  record  charac 


r characters 
containing 
e b loc k . Do 
ter  count. 


The  combining  of  sultiple  logi 
into  one  block  of  inforaation 
decrease  the  tise  wasted  due  t 
tion  and  deceleration  of  tape 
conserve  space  on  tape. 


cal  records 
on  tape  to 
o acceleca- 
and  to 


A special  geographic  retrieval  operator 
which  pereits  selection  of  file  records 
by  deter»ining  if  a point  carried  in  the 
file  record  falls  within  a circle  speci- 
fied as  the  search  criteria. 

A najor  functional  unit  within  NIPS  360  FPS. 
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Control  Field 
Control  Group 
Data  Base 

Data  File 


Data  Set 


Data  Record 


Dir  tioaar  y 

PPS 

FFT 

Field 

FLsld  Na»e 


Refer  to  record  control  field. 

Refer  to  record  control  group  or  record  ID. 

The  collection  of  data  files  (data  sets) 
used  under  the  system. 

Also  called  FFS  data  file  or  formatted 
file  or  file.  A collection  of  data  records, 
called  file  records,  which  can  be  logica llv 
grouped  on  the  basis  of  subject  natter. 

Since  the  organization  of  the  data  is 
foraatted,  the  file  is  called  a formatted 
file. 

NIPS  360  tern  essentially  implying  a data 
file.  Used  to  describe  a collection 
of  data  records,  stored  in  coa  non,  and 
accessed  as  an  entity. 

As  a general  ter*,  aeans  a group  of  related 
fields  of  data  treated  as  a unit.  often 
used  to  aean  FFS  file  record  (refer  to 
file  record)  . 

A user -defined  table  that  consists  of  all 
words  (including  any  synonymns)  that  are 
to  qualify  as  keywords  fro»  the  associated 
indexed  field. 

Formatted  File  System, 

File  Poraat  Table. 

The  smallest  defined  logical  unit  of  data 

in  a record  handled  by  the  PPS 

consisting  of  one  or  acre  adjacent  characters. 

The  synonym  or  mnemonic  assigned  to 
represent  a discrete  area  (field  or  group) 
in  the  data  record , 
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File 


File  Forxat 
Table 


File  ID 
File  Nnaionic 
File  Record 


FIT 

Plied  Field 

Fixed  fir  a up 
Fixed  Set 

FI 

For  a at 


Generally  a nonspecific  term  meaning  an 
organized  collection  of  information  directed 
toward  some  purpose.  However,  in  this 
documentation,  file  maans  FFS  data  file, 
unless  otherwise  qualified.  (Refer  to 
data  file.) 

A collection  of  records  which  completely 
describes  the  format  of  the  FFS  data  file. 

They  are  generated  by  the  File  Structuring 
Component.  There  is  one  FFT  for  each  data 
file. 

Name  of  the  FFS  data  file. 

Same  as  file  ID. 

(Also  called  data  record.)  A group  of 
related  fields  of  data.  The  file  record 
is  formatted  - that  is,  each  eltment  of 
the  file  record  has  been  defined,  identified, 
and  assigned  a relative  position.  Each 
file  record  ha  s a fixed  set  which  contains  the 
record  ID.  The  file  record  may  also  contain 
a number  of  periodic  sets  and/or  variable 
sets . 

File  Information  Table. 

A field  defined  in  the  fixed  set  of  a file 
record  and  which  must  appear  once  and  only 
once  in  the  file  record. 

Refer  to  group. 

That  portion  of  a file  record  consisting 
of  all  the  fixed  fields/groups  of  the  file 

recor d . 

System  component  --  File  H ai  n t en  an  ce . 

A predetermined  arrangement  of  characters, 
fields,  or  other  data.  A format,  does  not 
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Formatted  File 

PR 

PS 

Gro  up 


Hi  3 h -Order 
Pos ition 

HOP 

Index 


Index  Data  Set 


describe  the  data,  but  describes  its 
or  qanizat  ion , 

Refer  to  data  file. 

System  coapone  nt  --  Pile  Revision. 

System  ooaponent  --  File  Structuring. 

A collection  of  one  or  more  adjacent  fields 
of  the  sane  type  which  are  related.  A 
group  is  capable  of  being  processed  or 
otherwise  manipulated  as  a unit.  The 
system  may  treat  a group  the  same  as  a 
field.  The  fields  within  a group  in  no 
way  lose  their  individual  identities  and 
iray  be  treated  as  if  they  were  not  grouped. 

If  fixed  fields  are  grouped,  the  group  is 
a fixed  group.  A periodic  group  is  a 
grouping  of  periodic  fields. 

The  leftmost  (rest  significant) 
position  of  a field. 

High-Order  Position. 

A file  field  or  group  that,  has  been  specified 
as  part  of  the  File  Indexing  capability. 

The  fil®  is  cross-indexed,  by  Record 
ID,  on  the  contents  of  an  index  field. 

Fixed  fields  are  defined  as  secondary 
indexes,  variable  fields,  variable  sets 
and  f i xed-  1®  ng  th  alpha  fiel  ds  containing 
textual  data  are  defined  as  Keyword  Indexes. 

The  repository  of  all  information  required 
to  support  the  File  Indexing  capability. 

It  contains  all  secondary  and  keyword 
indexed  fields,  all  index  fields  values 
(or  keywords)  and  cheir  associated 
Record  I Ds. 
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Input 

Descriptor 
Input  File 

Input  Group 

Input  Group 
Control  Field 


Input  Record 


Input  Record 
Type  Coda 

Input  Table 
Subrout ine 


Ka  y w«rd 


Kayword  Indexing 


Li b rat  y 


A deck  of  cards  which  describes  the 
external  fonst  of  input  data  for  the 
FH  component. 

A card  or  tape  file  which  contains  all 
or  a portion  of  the  data  needed  by  FH 
to  update  a NIPS  data  file  (also  known  as 
a transaction  file). 

All  of  those  input  records  containing 
information  to  he  extracted  for  the 
purposes  of  creating  or  updating  a single 
(the  same)  file  record. 

An  artificial  control  field  or  an  actual 
data  field  (or  fields)  by  which  the  input 
file  is  sorted  or  annually  arranged  prior 
to  input  to  the  system.  This  is  done  so 
that  all  input  records  belonging  to  the 
same  input  group  (i.e.,  pertaining  to  the 
saae  file  racord)  will  be  grouped  together. 

A singla  card  (or  ta  ne  record)  in  an  input 
file. 

The  code  used  to  distinguish  one  i.iput 
record  type  from  another. 

A user-supplied  data  conversion/validation 
table  or  subroutine  utilized  to  convert 
data  from  its  external  fora  to  an  internal 
fora  required  by  the  uaer. 

A value  from  a keyword  indexed  field  that 
has  been  defined  as  a qualifying  value  for 
a specified  field  in  the  Index  Data  set. 

The  capability  to  provide  file-indexing  on 
values  (keywords)  included  in  textual  data 
fields. 

A partitioned  data  set  used  to  store  programs, 
subroutines,  tables,  R ITs,  retrievals,  and 
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queries.  The  term  library  may  also  be  used  to 
describe  the  partitioned  data  set  which  is 
allocated  for  the  subfile  capability. 

Logic  Statement  An  executable  load  nodule  generated  by  PM  from 

user  logic  specifications  to  perform  the  file 
update  function  for  one  transaction  type. 

Logical  Record  A collection  of  data  elements  which  is 

distinct  and  cosnlete  as  interpreted  by 
the  systea.  One  physical  record  (block) 

■ ay  contain  many  logical  records. 

ld?  Low-Order  Position. 

Low-Order  The  rightmost  (least  significant) 

Position  position  of  a field. 

Mnemonic  Generally  refers  to  a symbol  or  name  which 

stands  for  an  equivalent  machine-oriented 
valu  e, 

lode  Refers  to  the  method  by  which  data  is 

stored  in  a data  record  (i.e.,  alphameric, 
numeric,  or  coordinate).  Also  may  identify 
the  status  of  an  executing  component,  e.g., 
signon  mode,  update  mode  etc. 

Module  A term  used  to  refer  to  any  mix  of 

components,  sections,  phases,  routines,  or 
subroutines . 

Multireel  File  A file  so  large  as  to  require  more  than  one 

physical  reel  of  tape  for  storage. 

Multivolume  File  Same  as  multireel  file  except  it  may  pertain 

to  either  tape  reels  or  disk  packs. 

NIP?  NMCS  Information  Processing  System. 

DP  System  component  --  Output  Processor. 

DS/360  Systea/360  Operating  System. 
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Output  Table/ 
Subrout  in  e 

Pariodic  Field 

periodic  Group 

Periodic  set 

Phase 

Polygon  overlap 


PSSQ 

2DP 

QUIP 

QBT 

RASP 


A user -3 u ppl ied  data  conversion  table/ 
subroutine  vhich  is  used  to  convert  data 
from  an  internal  systea  fora  to  an 
external  fora  required  by  the  user. 

A field  defined  in  a periodic  set  of  a 
file  record,  and  vhich  nay  appear  nore  thin 
once  in  a file  record. 

Refer  to  group.  One  or  nore  contiguous 
fields  of  the  sale  periodic  subset, 
handled  as  one  logical  entity. 

A collection  of  periodic  subsets  having 
the  sane  focaat. 

A collection  of  routines  and/or  subroutines 
vhich  are  treated  together  as  a module 
loaded  in  core  together  (also  nay  be 
referred  to  as  an  overlay). 

A special  geographic  retrieval  operator 
which  permits  selection  of  file  records  on 
such  criteria  as  a point  falling  within  an 
area,  two  areas  overlapping,  a line 
intersecting  another  line,  etc.  See  PASP 
Users  Nanual. 

Periodic  subset  sequence  nuiber. 

Qualifying  Data  File  - An  output  of  RASP; 
this  data  set,  together  with  the  QFT 
performs  the  function  of  providing  an 
Answer"  file.  See  RASP  Users  Nanual. 

Systea  component  --  Quick  Inquiry  Processor. 

Qualifying  Record  Table  - See  QDF . 

Systea  component  --  Retrieval  and  Sort  Processo 
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Racori  Character 
Count  (Field) 

Raoorl  Control 

Record  ID  (also 
called  Record 
Control  Group  or 
Record  Key) 

PIT 

Ro  utia  a 

S a c o n i a r y 
Indexing 

Sec  + ion 
Sect ion/P  hase 

sat 

SODA 

Stop  Hock  Table 


A field  which  is  ths  first  two  characters 
of  every  logical  record.  It  contains  the 
count  of  characters  in  the  logical  record. 

Refer  to  Record  ID. 

The  initial  data  field  (s)  of  the  fixed  set 
which  «ake  each  file  record  in  a file 
unique,  and  are  used  to  identify  the  file 
record.  The  file  records  in  a file  are 
sequenced  according  to  the  contents  of 
their  record  control  group  or  record  ID. 

Report  Instruction  Table  generated  by 
OP  to  diract  output  format. 

A logical  collection  of  subroutines  and 
instructions,  and  is  a logical  portion  of 
a phase. 

The  capability  to  provide  file-indexing 
on  values  contained  in  fields  other  than 
Record  ID's  used  to  speed  up  the  retrieval 
process. 

A naaed  phase  (s)  for  a coaponent. 

when  there  are  no  phases  within  a section, 
the  section,  a single  operation,  is  termed 
a section/phase. 

A collection  of  fields  and  groups  of  the 
sane  type. 

System  coaponent  --  Source  Data  Automation. 

A user -defined  table  for  the  Keyword  Indexing 
capability  that  consists  of  values  that  are 
to  be  eliminated  from  consideration  as  keyword 
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S ud  f i I » 

s ua  rout  i.  a e 

Subset 

Table 

TP 

Transaction 

Variable  Pield 

VSCTL 

VSET 


A file  rfhich  is  a aeiher  of  the  subfile  partitioned 
data  set  and  consists  of  selected  entries 
f roa  a data  f i le  . 

A collection  of  machine  instructions  per- 
forms a simple,  single  logical  function, 
and  is  a logical  portion  of  a routine. 

A periodic  subset.  A segment  of  recurring 
information,  coaposed  of  periodic  fields. 

A collection  of  ar  gu  ment- funct  ion  pairs 
organized  for  efficient  searching. 

Systea  component  --  Terminal  Processing. 

An  input  record  to  the  Pfl  or  SODA  components 
which  contains  data  file  update  information. 


Each  set  in  a record  format  may  have  one 
variable  fiell  defined.  When  defined  it 
carries  no  size  specification  and  aay  be 
used  to  store  unformatted  data  of  variable 
lengths. 

Variable  sot  control  field. 

Variable  sat  - A segment  of  variable  length 
recurring  information. 
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Appendix  A 

PHYSICAL  DESCRIPTION  07  THE  NIPS  360  PF5  DATA 
FILE  AND  FILE  FORMAT  TABLE 


The  material  contained  in  this  appendix  is  quite 
technical  and  should  not  generally  be  needed  by  the  average 
user  of  the  NIPS  360  FFS.  However,  it  is  presented  here  for 
those  users  who  are  interested  in  the  actual  Banner  in  which 
data  is  referenced  and  stored  in  a file.  In  addition  it 
will  aid  users  who,  having  duaped  the  file  in  iaage  form, 
desire  to  locate  specific  iteas  of  information. 

Tha  NIPS  360  PFS  data  file  and  its  associated  File 

Foriat  Table  are  stored  as  a DATA  SET.  The  ter®  data  set  is 

the  DS/360  terminology  used  to  refer  to  a logical  collection 
of  data  which  is  accessible  to  the  systea  through  a unique 
name. 

A . 1 Data  Set  organization 

Ths  NIPS  360  FFS  data  set  is  built  and  maintained  using 

the  os/36  0 Indexed  Sequential  Access  Method  or  the 

Sequential  Access  Method.  Logical  records  in  the  data  set 
ar?  variable  length  and  aay  be  up  to  1,000  bytes  in  length. 
These  logical  records  are  blocked  into  physical  records 
which  have  a standard  or  default  saxiaua  size  of  1,004  bytes 
or  a larger  user  specified  size,  when  the  data  set  is 
iuiaxed,  each  logical  record  has  o key  field  used  to 
uniquely  identify  the  record.  The  generalized  format  of  a 
logical  record  in  the  data  set  is  as  shown: 


A - Four  bytes  used  for  OS  control;  contains  length 
of  record. 
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B - One  byte  used  as  a flag  to  contain  a delete  code 
when  the  record  is  to  be  retowed  fron  the  data 
indexed  set. 

C - This  field  is  the  record  key  containing  data  to 
uniquely  identify  the  logical  record  in  the  data 
set. 

P - This  portion  of  the  logical  record  contains  the 
actual  data. 


The  data  set  contains  several  categories  of  information 
in  its  logical  records.  The  primary  purpose  of  the  data  set 
is  to  contain  the  user's  di  ta  file  which  requires  the  bulk 
of  the  space  used.  AI30  contained  in  the  data  set  is 
supporting  information  consisting  of  the  FF?  and  the  FN 
logic  statements  used  during  file  maintenance.  Discussion 
in  this  appendix  is  limited  to  describing  the  format  and 
organization  of  the  PFT  and  data  file. 

The  first  character  in  the  record  key  of  each  logical 
record  in  the  data  set  is  used  as  a code  indicating  the  type 
of  inforxation  carried.  Being  first  in  the  key,  it  is  also 
used  to  cause  the  data  set  to  be  sequenced  in  ascending 
order  based  on  record  types.  The  general  order  of  record 
types  is  as  follows: 

a.  File  Foraat  Table  records 

b.  FB  Logic  Statement  records 

c.  The  Statistics  Record  for  ISAb  data  files 

d.  Segment.  Records  tor  Segmented  SAB  data  files 

e.  user's  Data  Pile  Records 

The  character  codes  used  are  as  follows: 

B - Classification  Record  FFT 
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C - Data  File  Control  Record  FFT 

D - Data  File  Index  Descriptor  Record  FFT 

E - Ncn-NIPS  Foraat/ID  Record  FFT 

F - Element  Format  Records  FFT 

L&n  - FH  Logic  Statement  Records 

N - Statistics  Record 

? - Segment  Records 

P - User's  Data  File  Records 


k.2  Data  File  Records 

The  format  and  or ganizat ion  of  records  making  up  the 
data  fila  are  discussed  in  this  section. 

Each  user  data  record  will  consist  of  one  or  more 

logical  records  in  the  oS/360  data  set.  There  will  be  a 

Logical  record  for  each  fixed  set  and  each  subset  in  a 
periodic  set  of  the  user  data  record.  The  major  key  field 
for  all  logical  records  related  as  a single  user  data  record 
will  be  the  sane  and  will  contain  the  record  control  group. 
However,  the  minor  key  fields  will  differ  based  on  set  type 

and  subset  number.  Within  the  data  base  records,  the 

storage  of  information  will  be  in  two  types  of  notation. 
For  alphameric  fields,  the  information  will  be  stored  as 
EBCDIC  characters  (i.e,,  one  byte  for  each  character).  The 
numeric  fields  will  be  stored  as  binary  words  (i.e.,  four 
bytes  used  in  binary  notation).  During  FS,  the  location  of 
binary  fields  within  the  logical  data  record  will  be 
controlled  so  as  to  conform  to  boundary  alignment 
requirements  when  the  data  record  is  brought  into  interna  J. 
memory. 

Whan  the  F3  component  is  executed,  the  format  for  the 
logical  records  is  created.  All  user- defined  record 
elements  for  the  fixed  set  will  define  a format  for  a 
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logical  record  used  to  contain  the  fixed  set.  All  user- 
defined  record  elements  for  a periodic  set  will  define  a 
tornat  to  be  used  with  each  logical  record  which  contains  a 
subset  of  data  and  so  forth.  In  addition  to  user -defined 
elements  of  a logical  record,  some  elements  are 
automatically  generated  by  the  PS  component  and  given 
special  names.  They  are  used  for  system  control.  Each 
distinct  element  in  a logical  record  (user  and  systea 
lafined)  has  a corresponding  logical  record  in  the  PPT  which 
contains  information  coapletely  describing  the  attributes  of 
the  element.  The  element  name  is  used  in  the  key  of  such 
records . 


The  maximum  size  of  the  user-defined  fields  in  a set.  can 
be  calculated  by  knowing  the  size  of  the  record  key  and 
system  overhead  fields.  An  FPS  set  (logical  record) 
consists  of  a maximum  of  1000  characters.  These  1000 
characters  are  split  among  the  record  key,  system  overhead 
fields,  and  user-defined  fields. 


Th? 

cons  ists 
o 

o 

o 


racord  key  contains 
of  the  following: 

One  byte  for  record 

One  byte  for  set  IP 

User  defined  major 


a minimum 

type  field 
fie  Id 

control  field 


of 


15 


bytes  and 


o User  or  system  defined  set  control  field. 

The  size  of  the  record  control  field  will  be  larger  if  the 
major  Record  ID  field  is  greater  than  seven  bytes  or  the 
periodic  sets  have  user -defined  control  fields  greater  than 
four  bytes. 


The  system  overhead  field  consists  of  a maximum  of  15 
bytes : 

o Pour  bytes  for  record  size  field 
o One  byte  for  deletion  code  field 
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o 

Maximum  of 

t hree 

bytes  f or 

full  word 

a 1 ignment 

prior  to 
record 

t he 

binary  block 

and  at  the 

end  of  the 

o 

Four  bytes 

f or  s 

ize  of  variable  field. 

The 

maximum  number  of 

use  r-d e f i ned 

cha  racte  rs 

in  u s er  - 

defined  fields  can  be  determined  by  summing  bytes  in  the 
record  control  field  and  system  overhead  field  and 
subtracting  this  total  from  1 000.  Whenever  the  sub  of  the 
thrae  categories  - record  control,  system  overhead,  user- 
defined  - exceeds  1 000,  PS  will  issue  an  error  ressaye. 

The  remainder  of  this  appendix  illustrates  the  typical 
format  for  data  file  records  when  they  reside  in  the  data 
set.  All  eLements  which  would  be  generated  are  shown. 

Elanants  which  were  directly  defined  by  the  user  with 
source  statements  using  the  PS  component  are  flagged  with 
the  character  MS"  (see  format  which  follows)  to  represent 
tha  generalized  case.  some  of  the  system  generated  elements 
Lave  names  which  start  with  the  character  This  is  used 

to  represent  a byte  containing  ail  zero  bits.  when  the 
format  for  a user's  defined  set  is  translated  into  the 
format  for  a logical  record,  all  numeric  fields  (binary 
words)  are  blocked  together.  This  is  to  ease  the 
requirements  for  binary  field  boundary  alignment  when  the 
logical  record  is  resident  in  core.  That  is,  data  can  be 
worked  using  machine  instructions  directly.  To  accomplish 
this,  whenever  the  logical  recoru  is  read  into  core  memory, 
the  record  is  started  on  a fullword  boundary  address.  Then, 
if  if  is  necessary,  slack  bytes  are  generated  by  FS  between 
tha  key  and  the  block  of  binary  words  in  the  logical  record 
to  force  the  binary  block  to  begin  on  a fullword  boundary  in 
core. 


whaa  PS  defines  the  format  for  a logical  record,  any 
needed  slack  bytes  are  accounted  for  in  the  record 
description . 
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(1»  Record  Size  Field 

Length  - Four  bytes 

Contents  - First  two  bytes  are  used  as  a binary 
halfword  to  indicate  logical  record 
length.  The  last  two  bytes  are  reserved 
for  OS  use. 


(2)  Deletioa  Code  Field 

Length  - One  byte 

Contents  - Field  is  set  to  all  binary  Is  by  the 
system  if  the  record  is  to  be  deleted 
froi  the  data  set  under  the  control  of 
the  I/O  Supervisor.  Otherwise  contents 
are  immaterial.  Mot  accessible  by  user. 


Thi  following  items  (3)  through  (6)  are  treated  together 
as  the  key  to  the  logical  record  and  contents  are  umgue  in 
tha  data  sot. 

(3)  Record  Type  Field 

Lea  gt  h - One  byte 

Contents  - The  character  "R"  to  distinguish  data 
records  within  the  data  set.  System 
generated  name  for  this  field  is  tFIL. 

(4)  Record  Control  Field 

Length  - Variable 

Contents  - Contains  the  data  record  control  group 
which  logically  ties  all  logical 
records  together  in  the  data  set 
which  are  related  to  each  other  (i.e., 
the  fixed  set  with  all  its  associated 
periodic  subsets)  . This  field  size  is 
specified  by  the  user  for  a particular 
data  set.  If  the  contents  for  a 
particular  data  record  are  shorter 
than  the  field  itself,  the  contents 
are  lef  t- j usti  f ied.  The  system  generat 
name  for  this  field  is  «-RCS. 

(5)  Set  ID  Field 

Length  - One  byte 
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Contents  - Uses  binary  notation  to  identify  whether 
the  logical  record  is  fi  »d  or 
periodic  in  nee.  If  periodic,  it  will 
identify  which  set  it  belongs  to.  The 
scheae  used  for  identification  is  - 
99999799  - Fixed  Set 
99999991  - 1st  Periodic  Set 


e 

11111111  - 255th  Periodic  Set 

The  systee  generated  nane  for 
this  field  is  *PCII. 


(6)  Subset  Control  Piald 

Length  - niniaua  of  four  bytes 
Contents  - When  a periodic  set  does  not  have  a 
secondary  ID  specified,  these  four 
bytes  are  used  as  a nuaber  (unsigned 
zoned  EBCDIC)  for  assigning  sequence 
nuabers  to  the  subsets. 

When  a periodic  set  has  a field  (s) 
specified  as  a subset  control  group, 
the  field  (s)  will  appear  in  the  access 
key  and  the  key  field  length  will  be 
adjusted  to  accoeaodate  it.  When  a 
periodic  set  has  a control  field 
defined  which  is  greater  than  four 
bytes,  then  the  length  of  this  key 
field  is  enlarged  to  accept  the 
control  data,  and  this  new  size  will 
appear  for  ail  periodic  sets. 

Periodic  sets  which  have  no  control 
field  will  have  their  sequence 
nuabers  left- justified  in  the  field. 
Pixed  sets  will  have  binary  zeros 
in  this  field.  If  necessary,  any 
padding  to  the  right  of  the  deciaal 
sequence  nuaber  will  be  with  binary 
zeros. 
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The  sy  ste s-generated  oases  for 
this  field  are  PSS3(n)  and  ♦SC  (b) 

■hen  no  subset  control  group  is 
defined  for  the  periodic  set.  If 
a sab  set  control  group  is  defined, 
the  only  systen- generated  naee  is 
♦ SC  (b)  . 

(Kota  (b ) stands  for  a byte  using 
binary  notation  to  express  the  set 
Barter.) 

(7)  Length  of  Binary  Data  Bloch 

Lea  gt  h - one  by  t e 

Contents  * tarter  of  fall  words  eating  up  the 

binary  data  bloch  in  the  data  record 
(field  9 and  10)  expressed  in  binary. 
Systee-generated  naee  for  this  field 
is  ♦BSE. 

(8)  Logical  Record  Paiding 

Leogth  - Variable  number  of  bytes. 

Contents  - Binary  zeros  for  the  nueber  of  bytes 
necessary  for  field  nine  to  begin  on 
a falltrord  boundary  in  core  seeory. 

(9)  Size  of  Variable  field 

Length  - Four  bytes  (binary  f allword). 

Contents  - Size  of  variable  field  if  existing. 

Otherwise  all  binary  zeros.  The 
eystea  generated  naea  for  this  field 
is  VSZ(n).  The  systee  naae  VSCTL  nay 
also  reference  this  field.  It  is 
the  first  variable  set  created. 

(10)  User-Defined  Muaeric  Pi-;  ids 

Length  - Each  is  four  bytes  (binary  fullvord) 

Contents  - user-supplied  numeric  data. 

(11)  User-Defined  Alphameric  fields  and  Groups 

Length  • variable  length  using  EBCDIC  characters. 

Contents  - User-supplied  alphameric  data. 
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(12)  Variable  Fields  (fixed  or  periodic  set) 

Length  - Variable  length  using  EBCDIC  characters. 

Coitents  - User -supplied  alpha  eerie  data. 

(13)  V aciable  F ield  (Defined  Variable  Set) 

Length  - Variable  as  specified  on  the  VSET 
source  language  stateeent  in  PS. 

Contents  - User-supplied  alphaaeric  data. 

(14)  The  first  byte  of  the  data  record  will  be  on  fullword 
boundary  align aent  . 

(15)  The  first  byte  of  the  binary  word  block  of  a data  record 
is  adjusted  by  the  padding  of  field  (8)  so  as  to  be  on 
fullword  boundary  alignment. 

(15)  The  low-order  byte  of  the  rightmost  binary  fullword  is 
addressed  by  entry  nueber  (16)  in  the  control  record 
for  a fixed  set  an  d by  entry  nueber  (19)  in  the  control 
record  for  a periodic  set. 

(17)  The  first  byte  of  a variable  field  is  referenced  by  the 
appropriate  user -assigned  nane  as  found  in  the  eleeent 
forest  record. 


The  following  discussion  defines  in  greater  detail  the 
operation  of  the  systee-generated  fields  PSSQ(n)  and  +SC(b). 

The  alnoc  sort  field  of  the  key  f or  a logical  record  is 
defined  as  the  Subset  Control  Field.  For  data  files  defined 
with  periodic  sets  in  which  no  subset  control  groups  were 
raguirad  (data  dependent),  this  subset  control  field  will  be 
four  bytes  in  length.  Two  oystes-gane rated  field  naaes 
(♦SC  (b)  and  PSSQn)  will  reference  this  field.  Its  contents 
will  be  decisal  nunbers  used  for  subset  sequencing. 

For  a data  file  hawing  sixed  periodic  sets  (i.e., 
periodic  sets  without  control  groups  and  sowe  with  control 
groups),  the  following  conventions  apply.  A PSSQ(n)  field 
nase  will  be  generated  only  for  those  sets  which  have  no 
control  group  and  reference  is  wade  to  the  first  four  high- 
order  bytes  of  the  subset  control  field.  A ♦SC(b)  field 
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naae  will  be  generated  for  all  periodic  sets  and  will 
reference  onlj  the  significant  lata  contained  in  the  subset 
control  field. 

An  exasple  fat  discussion  above,  consider  the  case  when 
a data  file  has  three  periodic  sets  defined.  Two  of  these 
periodic  sets  have  subset  control  groups  which  differ  in 
length.  In  the  following  forsat,  each  character  represents 
a byte. 
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PIXED  SET 


Record  Key 


1-1-1- 1-1-  l-lJllJC-g-£-£-£-g-C.£-£-£-L 


a - Record  10  Value 

B - Eight  binary  zeros  indicating  fixed  sat 
C - All  10  bytes  have  binary  zeros 


PERIODIC 
SET  1 

(10-characters 
periodic 
coatroL  group) 

B - Binary  content  of  byte  is 
indicating  1st  periodic  set. 

C - Contains  periodic  control  value. 

The  systes  generates  the  field 
naae  ♦SC(b)  for  this  10-byte  field. 
*b”  has  the  binary  value  QOWPWl. 


R |A  A 


Llfiis 


■A_A,  ,1,A1BJC_C  C C 


c C c c c c 1 


A - Record  ID  value 


PER  IODIC 
SET  2 

(5-character 
periodic 
control  group) 


C - contains  periodic  control  value. 

The  eystea  generates  the  field 
naae  ♦ SC ( b)  for  this  5- byte 
field.  NbN  has  the  value  pWOWTl?. 

D - Re  saining  five  bytes  are  padded 
tfith  binary  zeros. 


dl-1-1- 1- 1-  1-lK 


A - Record  ID  value 


B - Binary  content  of  byte  is  O'lfBBBlB 
indicating  second  periodic  set. 
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PERIODIC 
SET  3 

(No  periodic 
control  group) 

1 - Record  ID  value 

B - Binary  content  of  byte  is  (J'OWO'O'll 
indicating  third  periodic  set. 

\ 

C - Contains  the  subset  sequence  number. 

The  system  generates  the  field  naae 

♦ SC(b)  and  P SSQ  3 for  this  4-byte 
field.  *b  1 has  the  value  jSfifShp!)  11. 

D - Remaining  six  bytes  are  padded  with 
binary  zeros.  Note  that  the  length 
of  the  subset  control  field  in  the 
access  key  for  the  entire  data  file 
is  dependent  upon  the  largest 
periodic  control  group  defined. 

All  other  sets  have  their  values  left 
justified.  Also  the  naies  +RCM  and 

♦ SC(b)  are  generated  by  the  systea 
even  though  the  user-supplied  names 
for  the  saae  fields. 


Record  xey 


L<L_!_1_A_A_A_ZI 


Subset  Centro! — [ 


JJ£_C_£_£_D 


D D 


D_RJL 


1 


The  following  conventions  concerning  group  definitions 
during  PS  are  nsed: 

* An  alphameric  group  containing  all  alphaaeric  fields 
will  have  all  fields  In  EBCDIC  character  notation 
(■ode  code  "A")  • 

- An  alphaaeric  group  containing  one  or  nore  numeric 
fields  will  have  these  nuaeric  fields  generated  in 
zoned  EBCDIC  decimal  notation  (sods  code  nD") . 


106 


INTRODUCTION  TO  FILE  CONCEPTS 


- X nueetic  group  containing  all  numeric  fields  Mill 
have  all  fields  generated  in  zoned  EBCDIC  deciaal 
notation  (node  code  "D"). 

- i noaeric  group  containing  both  alphameric  and 
nuseric  fields  Mill  not  be  alloaed. 

- Nuaeric  fields  or  groups  say  not  be  used  as  record 
control  or  subset  control  groups.  Only  EBCDIC 
characters  a ay  be  used  in  the  access  key. 

- X coordinate  group  contains  fields  in  the  binary 
block  of  the  logical  records.  Each  field  is  a 
binary  word  capable  of  containing  either  a latitude 
or  longitude  value. 


X.  3 File  Foraat  Table  Records 

This  subsection  discusses  in  sequence  the  types 
records  found  in  the  FFT  portion  of  the  data  set. 


x.3.1  Classification  Record 

There  is  one  classification  record  in  the  OS/360  data 
set.  It  appears  first,  and  its  purpose  is  to  carry  the 
user- supplied  classification  label  defined  when  Pile 
Structuring  was  run.  The  forsat  for  the  classification 
record  is: 


UU1BU1SL  1EU LSI. 


cm: 


in 


L lllUlLXt.lL.. 


( X)  Record  size  field  - contains  X*104'  (for  files 

structured  under  360  NIF5),  or  E'109*  (for  files 
converted  fros  1410  to  360  BIPS) 

(B)  Reserved  for  OS 

(Q  Delete  ode  field  - contains  I*  00* 
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(D)  Record  type  field  - contains  C'B* 

(E)  Classification  - contains  classification  literal 
lef  t- justi  f led  in  a 32-byte  field.  Any  padding  to 
right  vill  bo  with  blanks, 

( f>  Date/Tiae  of  last  update  - contains  date/tiee  of 
last  FN  or  SODA  update  of  the  file. 

Poraat:  TTDDDHHRHSS  (year,  nay,  hour,  ainute,  second) 

(0)  Nun  bet  of  fields  indexed  - two  bytes  bJnary 

(R)  Nuaber  of  SUB/TAB  entries  in  all  Index  Descriptor 
R ecords 

(1*  Slack  bytes  to  bring  record  to  a size  greater  than 
a eaxiaua  key. 


A,  3. 2 Data  File  Control  Record 

Th a data  file  Control  Record  (s)  ppear  sequentially 
following  the  Classification  Record,  s purpose  '.s 

supply  inforaation  to  the  using  FFS  coaponent  on  t r 
or janizatlon  and  foraat  of  the  eleaent  foraat  records.  In 
a sense,  it  provides  the  bootstrap  iaforaetion  needed  for  a 
coaponent  to  interpret  correctly  the  eleaent  foraat  records. 

In  addition  it  supplies  basic  inforaation  on  the 

organization  of  the  resident  data  file. 

The  foraat  of.  the  data  file  control  Record  and 
description  of  its  contents  follow: 

3 roup  Repeats  for  each  periodic  set 

(Pi 

llll.J 

I 


(ll  Record  Size  Field 

Leo  gt  h - Four  bytes 

contents  - First  two  bytes  are  a binary  halfword 


(1)  (2)  (3) 


(<M  (5)  (6)  (7)  (8)  (9)  (10)  (11)  (12)  (13)  (19)  (15)  (16) 


LI 


1 


TmTTTT~nm 


\l 
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used  to  specify  record  length.  The 
list  two  are  reserved  for  OS  use. 

(2)  Deletion  Code  field 

Length  - One  byte 

Contents  - All  binary  Is  set  by  system  if  recocd 
is  to  deleted  fro*  the  data  set. 
Otherwise  contents  are  ieeaterial. 

Not  accessible  by  user. 

(3)  Record  Type  Field 

Length  - One  byte  EBCDIC 

Contents  - The  character  'C*. 

( U)  Control  Record  Key  Padding 

Length  - 254  bytes 

Contents  - Binary  zeros  throughout  all  bytes. 

Osed  to  force  the  fixed  inforeation 
carried  in  the  control  record  beyond 
the  largest  access  key  that  eay  be 
defined.  Bill  contain  a *C'  in  high- 
order  byte  in  continuation  records, 
followed  by  hezadecisal  blanks 
throughout  the  reminder  of  the  field. 

Hots : The  access  hey  for  the  control  record  is  eade  up  of 

field  (3)  and  all  or  part  of  field  (4)  depending  on  the 

length,  regained  for  the  data  file. 

(5)  High-Order  Position  of  Record  control  Group  in  the 
Record  Key  of  user  data  records  (logical). 

Length  - Binary  halfword 

Contents  - Location  is  relative  to  tbe  high-order 
byte  of  the  record  size  field  which 
is  based  at  zero.  Data  content 
of  this  field  in  continuation 
records  is  not  significant. 

(6)  Length  of  Record  Control  Group 

Length  - Binary  halfword 

Contents  - size  of  record  control  group.  Data 

content  of  this  field  in  continuation 
record  is  not  significant. 
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1 

4 

| 

(7)  High-Ordec  Position  of  Set  ID  Field  in  the  Record  of  User  5 

Data  Records  (Logical)  Key 

Length  - Binary  halfword 

Contents  - Location  specification  sane  as  (5). 

Data  content  of  this  field  in  con- 
tinuation record  is  not  significant. 

(8)  Length  of  Set  ID  Field 

Length  - Binary  halfword 

Contents  - Sire  of  field  (I  byte)  . 

Data  content  of  this  field  in  con-  , 

t.inuation  record  is  not  significant. 

(9)  High-Ordet  Position  of  Subset  Control  Group  in  the 
Record  Key  of  Usee  Data  Reoord  (Logical) 

Length  - Bina-y  halfword 

Contents  - Location  specification  sane  as  (5). 

Data  content  of  this  field  in  con- 
tinuation record  is  not  significant. 

(ID)  Length  of  subset  Control  Group 

Length  - Binary  halfword 

Contents  - If  no  periodic  set  control  group  for 
the  data  file  has  been  defined,  the 
size  aill  be  four  bytes,  otherwise 
the  size  of  the  largest  periodic  set 
control  group  specified  will  be  used. 

Data  content  of  this  field  in  con- 
tinuation record  is  not  significant. 

(11)  nuaber  of  Periodic  Sets 

Length  - Binary  halfword 

Contents  - The  nuaber  of  periodic  sets  defined 
for  the  data  file  up  to  179.  If 
aore  than  179  periodic  sets  were 
defined,  the  nuaber  in  excess  of 
179  will  appear  in  this  field  in 
the  continuation  record,  if  no 
periodic  sets  were  def  jd , this 
field  will  cont  in  bin.-rj  zeros. 
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(12)  High-Ordec  Position  of  Significant  Data  in  the  Eleaent 
Focaat  Records 

Length  - one  byte  using  binary  notation 
Coatents  - Provides  the  relative  high-order 
position  of  data  contained  in  the 
eleaent  foraat  records.  The  first 
byte  of  the  eleaent  foraat  record  is 
considered  at  a zero  location.  This 
field  is  used  because  there  aay  be 
byt  e padding  between  the  last  character 
of  the  access  key  and  the  first  byte 
of  data  contained  in  the  eleaent 
foraat  record.  This  will  allow  half 
boundary  alignaent  for  the  binary 
entries  in  those  records. 


(13)  Duaay  Entry 

Length  - Three  bytes 

Contents  - High-order  byte  contains  a *C*  if  a 
continuation  record  follows.  Data 
content  of  this  field  in  con- 
tinuation record  is  not  siginif icant . 


(Ik)  Length  of  Fixed  Set  Logical  Record 

Length  - one  byte  using  binary  notation 
Contents  - Size  in  fullwords  includes  record 
size  field,  deletion  code  field, 
access  key,  and  all  defined  fixed 
Length  fields.  In  addition,  it  aay 
include  soae  padding  (binary  zeros) 
at  end  of  set  so  that  the  entire 
logical  record  will  conform  to  fall 
word  boundary  alignaent.  Data  content 
of  this  field  in  continuation  record 
is  not  significant. 


(IS)  Nanber  of  Binary  Hords  in  the  Fixed  Set  Logical  Record 
Length  - one  byte  using  binary  notation. 

Contents  - Vuaber  of  fullwords  in  the  block  of 

binary  words  which  are  contained  in  the 
fixed  set.  Data  content  of  this  field  in 
continuation  record  is  not  significant. 
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(16}  Low-Order  Position  of  Binary  Block  in  Fixed  Set  (low-order 
byte)  Logical  Record 

Length  - Binary  halfword 

Contents  - Location  relative  to  the  first  byte 
of  the  record  size  field  which  is 

bs  sod  at  zero.  Data  content  of  this  field 
it.  continuation  record  is  not  significant. 

Note:  The  following  fields  in  the  control  record  are  optional. 

(17)  Length  of  First  Periodic  Set  Logical  Record 

Length  - one  byte  using  binary  notation 
Contents  - Size  in  fullwords  as  was  specified 
far  field  (14)  above. 

(13)  lusber  of  Binary  lords  in  First  Periodic  Set  Logical 
R eco  r d 

Lei gt  h - One  byte 

Contents  - Nuwber  of  fullwords  la  the  hlock  of 
binary  words  which  are  contained  in 
the  first  periodic  set.  Binary 
notation  is  used  in  this  field. 

(19)  Low-Order  Position  of  Binary  Block  in  the  First 
Periodic  Set  Logical  Record 

Leagth  - Binary  halfword 

Contents  - Position  specified  sane  way  as  for 
field  (16)  above 

Note:  The  fields  (17),  (IB),  and  (19)  will  be  repeated  as  a 
group  to  define  each  periodic  set,  up  to  a saxism  of  179 
sets.  k continuation  record  will  be  generated  to  255. 
Contents  of  fields  (17),  (18),  and  (19)  in  the  continuation 
record  is  as  stated  for  the  control  record.  See  paragraph 
A. 3. 5,  Continuation  Techniques,  in  this  appendix.  Nhile 
reading  this  appendix,  it  way  be  best  to  study  the  data 
record  foraat  foe  logical  records  contained  in  paragraph  A.  2 
of  this  appendix. 
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A. 3.  3 index  Descriptor  Record 

Ear*  field  or  group  in  the  user's  data  file  which  has 
been  specified  as  an  index  has  a special  record  in  the  data 
set  signifying  this  fact  as  well  as  containing  certain  field 
location  and  attribute  inforaation.  These  records  are  known 
as  Index  Descriptor  Records.  Each  is  a logical  record 
containing  in  its  key  field  the  field  or  group  naae  which 
has  been  indexed.  The  records  are  generated  along  with 
other  PPT  records  during  an  PS  run,  or  they  are  inserted 
into  an  existing  FFT  during  an  Index  Specification  run.  In 
addition  to  inforaation  supplied  by  the  user  on  Index 
Specification  statements,  eleaents  free  the  corresponding 
" F"  (Eloaent  Foraat)  records  for  that  field  or  group  are 
present  in  the  record. 

The  reaainder  of  this  section  illustrates  the  foraat  and 
contents  of  the  Index  Descriptor  Record. 


1 2 3 4 5 6 7 8 9 10  11  12  13  1»  15 

j_r _| [ — , — i ■.  1 — r~*- 
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( 1)  Record  Size  Pield 

Length  - Four  bytes 

Contents  - Pirst  two  byt^s  wake  up  a binary  half*- 
word  providing  the  size  of  the  logical 
record.  The  ia st  two  bytes  are  reserved 
for  OS  use, 

(2)  Deletion  code  Field 

Length  - One  byte 

Contents  - All  binary  I's  set  by  systea  if  the 

record  is  to  be  deleted  froa  the  data 
set  by  the  I/O  supervisor.  Otherwise, 
contents  are  iaaaterial. 

( 3)  Record  Type  Field 

Length  - One  byte  EBCDIC. 

Contents  - The  character  *D'. 


(4)  Field  or  Group  Naae 

Length  - Variable  nuaber  of  EBCDIC  characters. 
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Contents  - Data  record  ela 


at  naae. 


(5| 


Pad  di  ng 
Length 


Contents  - 


(6) 


variable  nuaber  of  bytes  required  to 
ensure  that  fields  u and  5 fill  space 
equal  to  that  of  the  record  key  for  the 

Binary  zeros  throughout  c.11  bytes. 


Boundary  Alignaent  Byte 


Length 
Contents  - 


One  byte,  if  necessary. 

\hfl*  if  * slaclc  hyte  *hich  Will  appear 
f f-iJ  SMry  t0  f0rce  811  following 
alig^n°t.  S6rVe  h8lfl'ocd  boundary 


(7l  Sit  Identification 


L ength 
Contents 


One  byte 
00000000 
000000 01 
00000010 
E tc  . 


in  binary  notation 

- Fixed  Set 

- Periodic  Set  1 
“ Periodic  Set  2 


<a>  Type  Identification 


Length 
Contents  - 


One  byte  using  binary  notation. 

The  content  and  foraat  of  this  byte  are 
identical  to  the  Eleaent  Type  Identifi- 
cation  described  as  eleaent  #9  under 
Section  A.  3.  4,  Eleaent  foraat 


<9J 


Record 


R ecords. 

High-order  Location  of  Eleaent  in 
Length  - Four  EBCDIC  bytes. 

Contents  - The  high-order  location  of  the  specified 

to beglnnin9  of  record 


(10)  Length  of  Eleaent  in  Logical  Record 


L ength 
Contents  - 


Three  EBCDIC  bytes. 

Irl  !dant?t  ?DJ  f°5*8t  of  this  «l«»ent 

arv  identical  to  the  Length  of  Eleaent  in 

Logical  Record  described  as  eleaent  f'M 
under  Sec tioe  ».3.u,  II *■’ 

S ecords , The  iae-order  Ml  (bit  7)  .Hi 
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be  set  to  1 for  « keyword  indexed  field. 

NOTE:  No  field  longer  tu arv  30  bytes 
■ay  be  specified  as  an  index.  There  is 
no  saxiaus  length  for  a keyword  indexed 
field,  however,  there  is  a naxiaQi  length 
of  30  for  any  designated  keyword  value 
within  the  field. 

(Ill  ELeeent  Node  in  the  logic  Record 

Length  - One  EBCDIC  byte. 

Contents  - A *A  lphi  ae  ric  , N-Nuseric,  C*Coor dinate 
or  D=Deciaal  are  the  acceptable  aodes. 

(12)  Input  Subroutine  Conversion  or  Stop  Word  Table  Naae 

Length  - Eight  bytes  EBCDIC. 

Contents  - Subroutine  naae  left  justified.  Blank 
if  no  conversion  on  input.  Asterisk  '•) 
left  justified  if  elenent  is  coordina  e 
■ode  and  has  external  length  of  5,  6,  7, 

8,  11,  or  15.  This  autoaat ically  invokes 

a standard  systea  conversion  subroutine. 
This  routine  is  specified  during  Pile 
Structuring  not  Index  Specification. 

For  a keyword  index,  this  field 
contains  the  na «e  of  thv  stop 
work  table,  if  one  were  designated, 
otherwise,  the  field  is  blank. 

(13)  PLLs  Porn  to  Index  Fora  Subroutine  Naae 

Length  - Eight  bytes  EBCDIC 

Contents  • Subroutine  naae  left  justified. 

For  a secondary  index,  the  naae 
specifies  a conversion  subroutine. 

For  a keyword  index,  the  naae  indicates 
the  dictionary.  The  field  is  blank 
if  a subroutine  or  table  is  not 
designated.  The  function  is  defined 
on  a SOB/TAB  statesent  during 
Index  Specification.  Refer  to  the 
RASP  wanual  (Voluae  IV)  for  a discussion 
of  this  function. 
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( 1 4|  Ana  1 yxer/Sc&n  Subroutine  Naae 

Length  - Eight  bytes  EBCDIC 

Contents  - subroutine  um  left  justified.  For 
a secondary  index,  it  designates  the 
naae  of  an  analysis  subroutine.  For 
a keyword  index,  it  designates  the 
naae  of  the  user  scan  subroutine.  The 
field  is  blank  when  a subroutine  is 
not  specified. 

(15)  Lxigth  of  Eleaent  as  Carried  in  the  Index  Data  Set/Hyphen 
Opt  ion 

Length  - one  byte  binary 

Contents  - Length  sinus  1 (e.g.,  a true  length  of  1 

becoaes  0 under  this  concept)  of  the  data 
as  it  is  actually  carried  in  the  Index 
Data  Set.  The  eleaent  length  has  no 
aeaning  for  variable  length  keyword 
data  in  the  index  data  set.  Therefore, 
for  keyword  indexes,  this  byte  will 
specify  the  option  indicating  how  a 
hyphen  is  to  be  treated  when  found 
within  the  data  field  of  a transaction 
record. 

( 1 6i  Fesarved  Byte 

Length  - One  byte  binary. 

Contents  - Zero. 

(17)  node  of  Eleaent  in  Index  Data  Sat  Forint 

Length  - One  byte  EBCDIC. 

Contents  - Saae  as  for  (11)  above,  but  this  entry 
refers  to  the  data  foraat  of  the  Index 
Data  Sat. 


Jk.  3.  u Eleaent  Foraat  Records 

Evary  eleaent  in  a user's  data  record  has  a special 
record  in  the  data  set  defining  its  location  and  attributes. 
These  records  are  known  as  Elaaeut  Foraat  Records.  Each  is 
a Logical  record  containing  in  its  key  field  tho  naae  of  the 
eleaent  that  it  describes.  The  records  are  generated  along 
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with  the  classification  and  control  records  by  the  PS 
coaponent.  In  addition  to  user-defined  record  elements 
(froe  Pile  structuring  source  statements)  additional 
elements  appear  in  the  logical  record  foraat  as  illustrated 
in  section  k,  2.  These  elements  are  generated  automatically 
during  structuring  for  internal  control  purposes.  They  have 
special  names  and  their  own  corresponding  Elesent  Format 
Records.  The  system- genera  ted  elements  and  their  purposes 
are  listed  below: 


a.  ^FIL 


b.  ♦ RCN 

c.  ♦PC* 

d.  ♦SC  (b) 


e.  ♦ BS  Z 


f.  PSSQ(n) 


This  e la  sent  contains  the  first  character  in 
the  logical  record  key  tAich  contains  "R. M 
This  character  is  coaeon  to  all  data  records 
and  is  used  to  batch  all  data  records  as  a 
block  within  the  0S/360  data  set. 

This  element  contains  the  total  record  control 
group  as  found  in  the  logical  record  key. 

This  element  contains  the  set  ID  field  in 
the  key  of  the  logical  record. 

This  element  redefines  the  subset  control 
group  in  the  key  for  a specific  subset  logical 
record.  The  fourth  byte  Id  the  nase(b)  will 
use  binary  notation  to  reference  a specific 
set;  foe  eiample: 

9977779  - Filed  sec 
9977991  - 1st  Periodic  set 
9777719  - 2nd  Periodic  Set 

This  element  will  occur  immediately  after  the 
key  in  a logical  record  (1  byte  in  longth)  and 
will  specify,  via  binary  notation,  the  number 
of  binary  fullwords  within  the  logical  record’s 
binary  data  block. 

This  eleaent  definition  is  generated  only  for 
those  periodic  sets  which  have  not  been  defined 
by  the  user  to  have  a subset  control  field 
(based  on  a data  value).  It  identifies  a 4- 
byte  field  in  the  key  of  a logical  record  used 
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for  subset  sequencing  within  a periodic  set. 

The  ter*  (n)  represents  a one -to -three  EBCDIC 
character  suffix  used  for  periodic  set  identi- 
fication; for  exaeple: 

PS5Q25  will  reference  the  subset 
sequence  field  for  a logical  record 
oc  Periodic  Set  2 5. 

g.  VSZ(n)  - This  element  is  the  first  binary  word  in  the 

binary  data  block  of  a logical  record  (fixed 
set  or  periodic  subset)  . This  binary  word 
will  indicate  the  nueber  of  characters  currently 
contained  ir.  the  logical  record's  variable 
field.  The  characters  indicated  by  (n)  will 
refer  to  the  periodic  set  involved  and  ate 
stated  using  EBCDIC  numbers.  For  exaeple: 

VSZ  - Pixed  Set 

?szl5  - 15th  Periodic  Set 

If  there  is  no  variable  field  for  a logical 
record,  this  field  (four  bytes)  will  contain 
binary  zeros. 

h.  TSCTL  - This  elesent  is  a redefinition  of  vsz  (n) 

element  for  the  logical  record  containing 
the  first  defined  variable  set. 

Mot):  The  syst  e*-generated  fields  (a)  through  (e) 
say  only  be  used  internally  by  the  FTS  co*ponent. 

No  analyst/user  aay  coasunicate  to  component  osing 
these  na*es.  In  contrast,  the  field  nates  PSSQ(n), 

VSZ(n)  and  TSCTL  aay  be  used  by  the  analyst  as  a 
sethod  of  controlling  this  particular  run.  The 
use  of  the  character  (t)  in  the  above  naaes  aeans 
a byte  consisting  of  binary  zeros.  Por  a coapleto 
understanding  of  the  use  of  the  generated  field 
naees,  it  aay  be  best  to  refer  to  the  description 
of  tae  data  record  found  in  section  2. 
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The  reeainder  of  this  section  illustrates  the  forest  and 
contents  of  the  Eleeent  Poraat  Record* 


Repeated  Croup  Possibly 


1L12L191 — 


a 


(3) 


(1)  Record  Size  Pield 

Length  - Pour  bytes 

Contents  - First  two  bytes  sake  up  a binary 

halfword  providing  the  size  of  the 
logical  record.  The  last  two  bytes 
are  reserved  for  OS  use. 


( 2)  Deletion  Code  Pield 

Length  - One  byte 

Contents  - All  binary  l's  set  by  systen  if  the 

record  is  to  be  deleted  froa  the  data 
set  by  the  I/O  Supervisor.  Otherwise 
contents  are  insaterial. 

(3)  Record  Key 

Length  - Variable  EBCDIC  characters.  Length 
is  standard  for  entire  data  set  and 
is  dependent  on  the  user  specifica- 
tions concerning  the  size  of  the 
record  control  group  and  the  periodic 
control  group  (if  defined). 

Contents  - see  (4)  and  (5). 

(4)  Record  Type  Pield 

Leo  gt  h - One-byte  EBCDIC 

Contents  - The  character  "P. " This  code  defines 
the  logical  record  and  an  Eleeent 
Foreat  Record. 


(5)  Eleeent  Naee 

Length  - Variable  length  EBCDIC  characters. 
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Contents  - Data  record  eleaent  name  left 

justified  within  this  portion  of  the 
access  key.  If  the  eleaent  naie  is 
less  than  seven  characters, 
it  is  padded  to  the  right  with  blanks 
until  a total  size  of  seven  is  reached 
After  that,  any  retaining  key  padding 
is  done  with  zero  bits.  See  Continua- 
tion Record  Techniques  at  end  of 
section  for  aodif  ications  on  continua- 
tion records. 

(G)  Boundary  Alignment  Byte 

Length  - One  byte  if  necessary 
Contents  - This  is  a slack  byte  which  eay  appear 
in  the  Eleaent  Poraat  Record.  This 
is  used  as  padding  to  force  all  follow 
ing  fields  in  the  record  to  observe 
halfword  boundary  alignment.  Entry 
12  of  the  control  record  is  used  to 
point  to  the  location  iaaediately 
following  this  byte  indicating  the 
start  of  record  data.  (High-order 
address  of  entry  V.) 

(7t  Dueay  Parameter 

Length  - Pour  bytes 

Contents  - Pull  characters  normally. 

Contains  ' C*  in  high- order  byte  in 
continuation  records. 

(8)  Eleaent  Set  Identification 

Length  - One  byte  in  binary  notation 
Contents  - Mtt999l3  - Pixel  Sat 

ff00W71  - Periodic  Set  1 
4*01*91?  - Periodic  Set  2 
Etc. 

Mot  used  in  continuation  records. 

(9)  Eleaent  Type  Identification 

Length  - One  byte  using  binary  notation 
Contents  - The  eleaent  definition  is  accomplished 
by  the  presence  of  bits  in  certain 
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locations  of  the  byte.  A bit  turned 
on  will  contain  a "1."  A bit  turned 
off  Mill  contain  a "0."  The  format 
of  the  byte  is  as  follows: 


Bit 

£Oj.  0123  4567 


JS  ON  - Pi  eld 

Q£?._lJLL21U2 

1 ON  - Pi  eld  or  group  is  used  for  record  or 
subset  control. 

tttt_=..jLaa-£s&lKdLjiae 

2 ON  - Systes  generated  field/group 

22£_r_tts0£-2fclifie!_£Agl^a£oyE 

3 ON  - Field/group  say  not  be  used  by  the 

analyst. 

£r£_r-£i§13/sisyp_is_^Masiiicisd 

4 ON  - Fixed  Length  Field 

o?ie_jiJtai_!iixsl_Lftiiath 

5 ON  - Variable  Length  Field 

«fI_.:Ji2t_IALi§blfi_l§J}Stk ... 

6 on  Variable  set  field 

aEX-l-Egfl-  ILUlkil-gAl-tU-U 

7 Always  0. 


0 1 2 3 4 5 5 7 
0 10  0 10  0 0 

The  file  forsat  record  describes  the  user 
defined  record  control  group.  The  fiel*’ 
is  not  used  in  continuation  records. 
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The  her  values  of  this  byte  for  all  elenent 
types  ace  sunnarized  below. 

A.  Systen  Generated  Elaaents: 

♦ FI  L 

♦ 8CE  X*  P8’ 

♦ PCE 
♦SC  (B) 

VSCTL  1 1 A8  * 

VST  (n) 

PSSQ(n)  - X*  18* 

♦ BSZ  - X ' B8* 

B.  User-Defined  ELeseats: 


Moa-control  field  - X»88* 
Non-control  group  - X'08* 
Variable  set  nane  - X’82' 
Variable  field  - X*B4  • 

Control  field  - X*C8* 

Control  gronp  - X*48' 


(10)  High-Order  Location  of  Elenent  in  Logical  Record 

Length  - Pour  bytes  using  EBCDIC  notation 
Contents  - Location  is  relative  to  the  high-order 
byte  of  the  record  size  field  which 
is  based  at  zero.  Data  content  of  this 
field  in  a continuation  record  is  not 
significant. 

(11)  Length  of  Elenent  in  Logical  Record 

Length  - Three  bytes  using  EBCDIC  notation 
Coatents  - (A)  Length  is  specified  for  the 

nunber  of  alphaaeric  characters 
represented.  For  alphaeeric 
■ ode  elements  (A),  this  will  be 
the  actual  nunber  of  bytes 
appearing  in  the  data  record. 

Por  nuneric  node  eleaents  (B)  , a 
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binary  word  {4  bytes)  will  appear 
in  the  logical  record  regardless 
of  the  length  specified.  For 
deciaal  Bode  eleaents  (D)  , this 
value  will  be  the  actual  nuaber 
of  bytes  in  the  logical  record. 

See  paragraph  (12)  below  for  a 
discussion  on  eleaent  nodes. 

(B)  If  this  is  a variable  field,  the 
entry  wtl’  contain  the  nuaber  of 
characters  per  line  to  be  printed 
during  output. 

(C)  If  this  is  a variable  set  field, 
the  length  is  as  specified  in  the 
VSET  FS  stateaent. 

(0)  Coordinate  node  eleaents  are 
handled  in  a special  aanner. 

The  sixe  appearing  in  (11)  depends 
on  certain  circuastances.  The 
Eleaent  Foraat  Records  generated 
to  define  coordinate  fields/groups 
are  siailar  to  other  user-defined 
fields /groups  with  the  following 
exceptions  noted: 

ALL  FIELDS  defined  for  coordinate 
use  and  single  coordinate  groups 
(one  latitude  field  and  one  long- 
itude field)  will  carry  the  external 
deciaal  length  value  (i.e.„  length 
as  defined  by  user  in  the  FS  field 
stateaent)  in  the  eleaent  foraat 
as  paraaeter  (11)).  All  groups 
defining  aore  than  one  coordinate 
point  will  carry  the  actual  internal 
length  in  bytes  of  the  binary 
representation  of  the  coordinates 
(internally,  latitudes  and 
longitudes  are  each  represented 
by  a fall  binary  word).  For 
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eiaaple,  if  POINT  is  defined  as 
a field  of  length  of  11  , represer> 
ing  both  latitude  and  longitude, 
the  length  carried  in  entry  11 
of  the  Eleaent  Poraat  Record  will 
be  11.  If  POINT  is  defined  as  a 
group  of  two  fields  of  length 
5 and  6 characters,  the  length 
of  the  group  trill  be  specified 
in  the  Eleaent  Poraat  Record  as 
11  (representing  the  sua  of  the 
two  fields).  If  LINE  is  defined 
as  a group  of  two  coordinate 
fields,  each  characters  long 
externally,  the  length  of  the 
group  will  be  specified  in  the 
Eleaent  Poraat  Record  as  16 
bytes  for  the  four  full  binary 
words  representing  the  coordi- 
nates internally. 


Three  cases  and  their  handling  during  PS: 

Case  1 - A user  defines  a single  coordinate  field 
intending  to  store  both  latitude  and  longitude 
values  ia  it.  The  field  will  be  either  11  or  15 
characters  in  length  depending  on  the  precision 
desired. 

The  PS  coaponent  will  cause  a single  eleaent  foraat 
to  be  built  with  the  n&  ae  supplied  ty  the  user. 
However,  this  record  will  define  two  adjacent 
binary  words  in  the  block  portion  of  the  logical 
record,  and  will  address  the  high-order  byte  of  the 
leftaost  word.  The  length  of  the  coordinate  field 
will  be  specified  as  either  11  or  15  characters  as 
defined  by  the  analyst  in  paraaeter  11  of  the 
Sleaent  Poraat  Record. 

Case  2 - A user  defines  two  fields  of  length  5(7) 
and  6(8)  characters  intending  to  Identify  latitude 
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and  longitude  separately,  in  addition*  a group  is 
defined  as  containing  these  two  fields. 

The  PS  component  will  cause  two  adjacent  binary 

fields  tD  be  generated,  with  an  Bleaejt  Format 

Record  for  each.  The  contents  of  the  Element 

Format  Record  describing  each  field  will  be  as  in 

case  one,  except  that  the  field  length  entry  (11) 
will  describe  only  the  user-specified  length  for 
that  field.  The  group  foraat  record  will  contain 
the  sum  -<f  the  user-specified  length  of  each  field 
defined  in  the  group. 

Case  3 - A user  has  defined  several  sets  of 

coordinates  by  the  method  of  case  one  or  case  two, 
as  discussed  previously.  In  addition,  he  defines 
this  collection  as  a group. 

In  addition  to  the  Element  Format  Records  generated 
as  in  cases  one  or  two,  the  PS  component  will 
generate  a group  format  record  describing  this 
collection  of  fields.  Parameter  11  in  the  group 
format  record  will  state  in  bytes  the  space  needed 
for  binary  words.  This  field  is  filled  with  null 
characters  in  continuation  records. 

(12)  Element  node  Specification 

Length  - one  byte  using  EBCDIC  notation 
Contents  - Alphameric  mode  element  (A). 

Numeric  mode  element  (B). 

Coordinate  mode  element  (C)  . 

Decimal  mode  element  (D) . 

(Decimal  mode  is  implicit  in  Pile 
Structuring  and  is  assigned  to 
numeric  fields  included  in  a GROUP 
statement.)  The  data  content  of  this 
field  in  a continuation  record  is 
not  significant. 

(13)  Input  Subroutine  Conversion  Naae 

Length  - Eight  bytes  EBCDIC 

Contents  - Subroutine  naee  left  justified. 

Zero  bits  if  no  conversion  on  input. 
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Asterisk  (*)  lef t-justif ied  if  element 
is  coordinate  mode  and  has  external 
length  of  5,  6,  7,  8,  11,  or  15.  This 
invokes  automatically  a standard 
systea  conversion  subroutine. 

Data  content  of  this  field  in  a 
continuation  record  is  not  significant 

(14)  output  Subroutine  Conversion  Name 

length  - Eight  bytes  EBCDIC 

Contents  - Subroutine  naae  left  justified. 

Zero  bits  if  no  conversion  on  output. 
Asterisk  left  justified,  same  as  (13). 
Data  content  of  this  field  in  a 
continuation  record  is  not  significant 

(15)  High-Order  Location  of  Eleaent  Label  in  this 
Poraat  Record. 

Length  - Binary  halfword 

Contents  - Location  specification  sane  as  (10) 
if  label  present. 

All  zero  bits  for  no  label. 

Bull  characters  in  continuation 
records. 

(16)  Length  of  Eleaent  Label  in  this  Eleaent  Poraat  Record 

Length  - Binary  halfword 
Contents  - Size  if  label  exists. 

All  zero  bits  if  no  label. 

Data  content  of  this  field  in  a 
continuation  record  is  not  significant 

(17)  High-Order  Location  of  Edit  Bask  this  Element  Format 
Record 

Length  - Binary  halfword 

Contents  - Location  specification  sane  as  (8) 
if  pattern  assigned  to  eleaent 
daring  Pile  Structuring. 

All  zero  bits  if  no  pattern. 

Data  content  of  this  field  in  a 
continuation  record  is  not  significant 
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(13)  Length  of  Edit  Hash  in  this  Eleaent  Potaat  Record 
Length  - Binary  halfword 

Contents  - Size  it  pattern  assigned  to  eleaent 
during  File  Structuring. 

All  zero  bits  if  no  editing  is  used. 

Data  content  of  this  field  in  a 
continuation  record  is  not  significant. 

Note:  when  edit  easts  appear  in  eleaent  Foraat  Records, 
they  are  in  PPS  edit  pattern  fora. 

(19)  Size  of  Eleaent  on  Output 

Length  - Binary  halfword 

Contents  - This  field  contains  the  size  (in 
bytes)  for  output. 

If  output  conversion  is  used,  the 
size  of  the  subroutine  output  is 
provided  . 

Data  content  of  this  field  in  a 
continuation  record  is  not  significant. 

(231  High-Order  Location  of  the  String  of  Field  Naaes  in 
the  Record  Waking  up  thB  Group 
Length  - Binary  halfword 

Contents  - Location  specification  sue  as  (ID) 
if  required. 

All  zero  bits  are  used  if  entry  is 
not  a group. 

Data  content  of  this  field  in  a continuation 
record  is  not  significant. 

(21)  Nuaber  of  Fields  Waking  up  the  Group 

Length  - Binary  halfword 

Contents  - Size  if  reguireaent  exists. 

All  zero  bits  if  not  required. 

All  the  following  entries  are  optional  and  are  used  if  required. 

(22)  Field  Label  Used  for  Output 

Length  - Variable  (EBCDIC  Character) 

Contents  - User-assigned  label  naae. 

Not  used  in  continuation  records. 


127 


introduction  to  file  concepts 


(23t  Edit  flask  ratteen 

Length  - Variable  (EBCDIC  characters) 

Contents  - Edit  pattern. 

Not  used  in  continuation  records. 

(24)  Field  Name  within  Group 

Length  - Eight  bytes  EBCDIC 
Contents  - Field  naee  left  justified. 

(25)  High- Order  Location  of  Field  in  Logical  Record 

Length  - Four  bytes  in  EBCDIC  notation 
Contents  - Location  specification  same  as  (10)  . 

(28)  Length  of  Field  in  Logical  Record 

Length  - Three  bytes  in  EBCDIC  notation 
Contents  - Length  specification  suae  as  (11). 

(27)  character  Set  Specification 

Length  - One  byte  EBCDIC 

Contents  - A - alphameric  field  (EBCDIC) 

D - decimal  field  (EBCDiq  . 

Note:  Fields  24-25-28-27  nay  appear  as  multiple  entries 
scarifying  from  left  to  right  the  fields  making  up  the 
group  for  which  the  current  record  is  identifying.  All 
system-generated  fields  will  use  entries  (1)  through 
(10)  with  the  exception  of  ♦ HCN  and  ♦ SC(B)  which  will 
list  all  user-defined  fields  making  up  the  control  group 
with  entries  (20),  (21),  and  (24)  through  (27). 

A. 3. 5 File  Statistics  Record 

NIPS  files  that  have  been  generated  in  ISAM  and  VSAM 
organisation  will  contain  a statistical  ( N)  record.  If  the 
file  has  been  generated  in  segoential  organization  a 
statistical  record  will  not  exist,  however,  a statistical 
record  will  be  generated  when  the  sequential  file  is  copied 
to  ISAK  or  VS  AH  organization  using  the  NIPS  UTBLDISfl 
utility.  The  statistics  record  is  maintained  by  a NIPS 
utLLity  waeo  the  file  is  generated  or  updated  and  certain 
information  concerning  lengths  of  NIPS  records.  The 
following  information  is  recorded  in  the  ' N*  rec>rd: 
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a.  Nuaber  of  sets  described  by  the  • record 

b.  Nuaber  of  sets  in  the  file 

c.  Length  of  the  longest  subset  for  each  set 

1.  Maxima  nuaber  of  subsets  foe  each  set. 

Tht  resaindec  of  this  section  illustrates  the  forest  and 
contents  of  the  Pile  Statistics  Record. 


REPEATED  FOB  BACH  SET 

[ii^innarjniiaiazzzziz^— 

( 1|  Record  size  tield 

Length  - Pour  bytes 

Contents  - Pirst  two  bytes  aaxe  up  binary  half-word 
providing  the  size  of  the  logical 
record,  the  next  two  bytes  are  not 
used. 

(2)  Deletion  Code  Field 

Lengt  h - One  byte 

Contents  - All  binary  1*b  set  by  systea  if  the 

record  is  to  be  deleted  froa  the  data 
set  by  the  I/O  supervisor,  otherwise, 
contents  are  immaterial. 

(3j  Record  type  field 

Leo  gt  h - One  byte 
Contents  - The  character  *N* 

(4)  Continuation  Nuaber 

Length  - one  byte 

Contents  - First  •»»  record  h' ank.  continuation 
record  contains  a nuabor  indicating 
order  of  sequence  starting  with  1. 

(5|  Nuaber  of  Sets  Described  by  'S'  Record 
Length  - one  byte 
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Contents  - Nuaber  of  sets,  including  the  fixed 
set  described  by  the  ' N * record, 

(6)  Highest  ' N'  Record 

Lengt  h - Ido  bytes 

Contents  - Pirst  byte  contains  an  in  EBCDIC. 

Second  byte  contains  highest  continuation 
nuaber  for  * M*  records  in  this  file. 

(T\  High  Otder  Position  of  Significant  Data 

Length  - One  byte 

Contents  - High  order  position  in  the  *N*  record, 
of  the  description  of  the  first  set 
(fixed)  in  the  file,  (see  field  II). 

(9)  Nuaber  of  sets  in  the  file 

Lei  gt  h - One  by  t e 

Contents  - Nuaber  of  sets  in  tha  file. 

(10)  Beserwed  by  future  use 

Length  - Three  bytes 

Contents  - Binary  zeroes. 

(11)  Length  of  Longest  Set  £ in  the  File 

Leagth  - Pour  bytes 

Contents  - Contains  the  total  length  of  all 

subsets  for  the  longest  set  £ for  a 
single  NIPS  record  in  the  file. 

(12l  Naxieua  Nuaber  of  Subsets 

Length  - Two  bytes 

Contents  - Contains  the  eaxiaua  nuaber  of  subsets 
for  the  longest  set  & for  a single  NIPS 
record  in  the  file. 

Nota:  Fields  11  and  12  will  repeat  once  for  each  set  in  the 

file. 

A . 3.  6 rile  Segaent  Becord 

Seguantial  files  thnt  have  been  segeented  contain 
segeent  records  (P)  that  specify  the  range  of  record  control 
values  pereitted  for  a segaent  and  the  voluae  serial  nuaber 
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of  the  segsent.  A file  seg  se  nt  uy  be  cosposed  of  core  than 
on)  range  of  reords,  A aegaent  record  *111  be  generated 
for  each  range  of  records  in  one  data  set. 

The  reaaindec  of  this  section  illustrates  the  foreat  and 
contents  of  the  File  Segsent  Record. 


1 

2 

3 

u 

5 

6 

( 1)  Record  Size  Field 

Length  * Pour  bytes 

contents  - First  two  bytes  take  up  a binary  half- 
word providing  the  size  of  the  record. 
The  last  two  bytes  are  reserved  for  OS 
use. 

(2)  Deletion  Code  Field 

Lea  gt  h - One  byte 

Contents  - All  binary  1*s  set  by  OS  if  the  record 
is  to  be  deleted. 

(3)  Record  Type  Field 

Length  - One  byte 

Contents  - The  character  'P' 

(4)  File  Record  Control  Value  (Low  Range) 

Length  - Variable;  based  on  sajor  record  ID 
la  ng  th . 

Coitents  - Record  control  value  that  is  assigned 
as  the  low  range  lisit  for  data  file 
records  on  this  segsent. 

(5)  File  Record  Control  Value  (High  Range) 

Length  - Variable;  based  on  sajor  record  ID 
lengt  h. 

Contents  - Record  control  value  that  is  assigned 

a)  the  high  lisit  for  data  file  records 
on  this  segsent. 
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(6)  volume  Serial  Nuri>er 

Length  - Si*  bytes 

Contents  ~ Volume  serial  number  for  data  file 

where  range  of  records  are  indicated 
in  the  • P'  recor d. 


A.  3.7  Continuation  Recoc  d Techniques 

There  are  occasions  when  the  data  contents  of  the 
control  record  and  group  foraat  records  lay  exceed  the  1,000 
byts  Logical  record  size  allowed  in  the  OS/360  data  set. 
This  section  describes  the  unner  in  which  the  File 
Structuring  component  handles  such  cases. 


A.3.7.L  Continuation  Records  for  the  PPT  Control  Record 

Because  of  the  logical  record  length  Liaitationa,  the 
control  record  is  only  able  to  supply  information  on  a 
aaxLmui  of  179  periodic  sets.  Since  the  systea  has  been 
designed  to  handle,  theoretically,  up  to  255  periodic  sets 
Lor  each  naaed  data  set,  it  becomes  necessary  to  provide  a 
continuation  record  when  the  nuaber  of  periodic  sets  defined 
by  the  user  exceeds  179.  when  such  a case  occurs,  a second 
control  record  will  be  created  to  continue  the  information 
on  periodic  sets  (entries  17-18-19). 

The  prieary  (first)  control  record  specifies  the  total 
nuaber  of  periodic  sets  that  it  defines  In  entry  11.  The 
high- order  byte  of  entry  13  contains  the  character  "C" 
inlLcating  that  a continuation  record  follows.  The 
secondary  control  record  will  have  the  saee  format  ms  the 
prieary.  However,  it  will  have  the  character  ”C"  in  its  key 
iwealiately  following  the  record  type  field  (entry  3).  The 
entries  5-10  and  12-16  are  not  laintained,  but  their  length 
is  the  same  as  in  the  priiary.  Entry  11  contains  the  number 
of  periodic  sets  defined  by  the  secondary  record.  Entries 
17,  18,  and  19  are  used  and  repeated  until  all  periodic  sets 
have  been  accounted  for. 
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A. 3. 7. 2 Continuation  Records  for  Group  Format  Records 


Sieilar  to  the  problea  faced  by  the  control  record,  the 
Eleeent  Format  Record  for  a group  may  experience  overflow 
cases.  This  overflow  of  data  resalts  from  the  series  of 
antries  which  lists  each  field  (group)  contained  within  the 
defined  group.  The  following  table  illustrates  the  number 
of  fields  that  a group  foraat  record  eay  define  using  a 
single  logical  record. 


OS  Fields 

PPT  Record  key 

REC3RD  Fixed  entries 
ENTRY 

LENGTHS  Field/group  label 
Edit  pattern 


five  bytes 

froe  8 to  255  bytes 

40  bytes 

froe  0 to  132  bytes 
fros  0 to  132  bytes 


Pield  length  specs 

in  group  format  record  16  bytes  per  field 

a.  &2X91  case  assuming  max  hey,  label,  and  edit  length  will 
allow  27  fields  (groaps)  to  be  defined  as  a single 
group  within  a 1,000-byte  record. 


b.  Bgst  case  assuaing  min  key,  and  no  label  or  edit  pattern, 
will  allow  59  fields  (groups)  . 


c,  lifitsai,  case  with  key  length  of  15  bytes,  label  length  of 
8 bytes  , and  edit  length  of  8 bytes  wiLl  allow  57 
fields  (groups)  . 


whan  a continuation  record  is  generated,  entry  21  in  the 
priaary  record  will  state  only  the  nuaber  of  fields  that  it 
lists.  The  high-order  byte  of  entry  7 will  contain  the 
chitacter  "C"  to  indicate  that  continuation  record(s) 
follow.  The  continuation  records  will  have  the  saae  foraat 
as  the  priaary.  However  entries  8 through  20  will  not 
cont  '■  valid  data  and  entries  22  and  23  will  not  appear. 
The  secondary  record  key  will  contain  the  group  naae,  as 
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usual,  but  will  be  suffiied  by  an  aighth  byte  using  binary 
notation  to  indicate  the  nuaber  of  the  continuation  record. 
The  first  cootinuatior  record  Mould  contain  "1"  in  binary 
,n1  so  earth  Entry  21  in  the  continuation  record  sill 
contain  a nueber  indicating  hoe  many  fields  are  contained  in 
the  list  of  entries  2b,  25,  26,  and  21. 


1.3.9  N on- MIPS  Pornat/ID  Record 

when  a pseudo-FFT  is  structured,  one  or  aore  records  ace 
cri  a ted^hich  contain  the  for.at/ID  table.  This  table 
describes  the  location  of  each  Potion  of  the  user 
designated  record  ID  wlthia  each  record  foraat.  The  table 
is  ordered  as  the  different  fornats  were  defined  in  FS. 

The  foraat  of  the  non-NlPS  Foraat/ID  record  and  description 
of  Its  contents  follows:  / — \ 


u 


.oil M — 


(1)  Record  Size  Field 

Length  - Four  bytes. 

Contents  - First  two  bytes  sake  up  a binary 
hr  ^f  word  providng  tha  size  of  the 
logical  record.  The  last  two  bytes 
ace  reserved  for  OS  use. 

(2t  Deletion  Code  Field 

Length  - One  byte.  . . 

Contents  - All  binary  Vs  set  by  systee  if 
the  record  is  to  be  deleted  froa 
the  data  set  by  the  I/O  supervisor. 
Otherwise  oontents  are  iesateri&l. 
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(3)  Record  Type  Pield 

Lea  gt  h - One  by  te. 

Contents  - The  character  "E".  This  code 

identifies  the  record  as  a non-NIPS 
fornat/iD  record. 

(4)  Continuation  Indicator  field 

Length  - One  byte. 

Contents  - Binary  zeros  for  the  first  "EM 

record  or  the  character  "C"  if  the 
record  is  a continuation  of  a 
previous  «E"  record. 

(5i  Continuation  Sequence  field 

Length  - One  byte. 

Contents  - k binary  sequence  nueber  starting 
with  a binary  1 for  the  first 
continuation  record. 

( 6|  Control  Record  Key  Padding 

Length  - Si*  bytes. 

Contents  - Binary  zeros  to  insure  proper 
sorting  of  the  FFT. 

Fields  7 through  10  are  repeated  for  each  record  foreat 

defined  in  the  FPT. 

(7|  Next  Segeent  Offset 

Length  - Binary  halfword. 

Contents  - The  offset  to  the  next  segeent  of 
the  "E"  record.  The  offset  is 
relative  to  the  beginning  of  the 
record.  When  the  offset  is  all 
binary  1 's,  the  next  segeent  is 
in  a continuation  T record,  when 
the  offset  is  all  binary  zeros,  this 
is  t he  final  segeent. 


(8)  Record  Type  Code 

Length  - Variable,  eaxieue  of  10  bytes. 
Contents  - The  record  type  code  used  to 
uniquely  identify  the  current 
record  foreat. 


135 


INTRODUCTION  TO  PILE  CONCEPTS 


(9)  hlignaent  Byte 

Length  - One  byte,  when  used. 

Contents  - Iaaaterial,  use]  to  force  halfword 
alignment  foe  field  10. 

(10)  Record  I Segaent  Descriptor 

Length  - Four  bytes. 

Contents  - This  field  consists  of  two  halfword 
binary  fields.  The  first  field 
contains  the  relative  high-ordar 
position  of  the  record  ID  aegaent. 
The  second  field  contains  the 
length,  in  binary,  of  the  record  ID 
segaent.  These  two  fields  are 
repeated  as  necessary  to  describe 
each  segaent  of  the  record  ID  in  the 
current  record  foraat. 
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Appendix  B 

DESCRIPTION  AND  USE  OP  THE  TRANSACTION  RECORDS  OOTPOT 
BT  THE  PILE  ANALYSIS  STATISTICS  CAPABILITY 


The  material  in  this  appendix  illustrates  the  us«  of  the 
tnnsa-tlons  that  are  output  by  the  File  Analysis  Statistics 
capability.  A saaple  of  the  two  transaction  fornats  are 
includal.  Saaple  FPT,  logic  statements,  queries,  and  RITs 
are  shown  illustrating  a possible  use  of  the  transaction 
records. 

B.1  Saaple  Transactions  from  File  Analysis  Statistics 

Transaction  Record  - OTPLDSCN  50  bytes 

1 2 3 4 5 

STEST360PHWffESTOmWWSEF¥WW0000000030  31771)l)X 


Column  1 - 

CHABAC'fE  P 'S' 

2-8  - 

FILE  NAME 

9-12  - 

COMPONENT  NAME 

13-25  - 

SOURCE  MODULE  NAME 

26-33  - 

FIELD  MARE 

34-36  - 

SET  NUMBER,  DECIMAL 

37  -42  - 

COUNT  OF  REFERENCES,  DECIMAL 

43-48  - 

DATE  - HMDDYY 

49-50  - 

UNUSED 

Traa  saction 

Record  - Component  Execution  50  bytes 

1 

2 3 4 

CTBST  3 60F  Rj»)*T  E S TOW  AJJJSMJ5JJOOO  0 26£WX3  31  771  yWW  MOW* 

Column  1 - 

CHARACTER  *C* 

2-8  - 

FILE  NAME 

9-12  - 

COMPONENT  NAME 

13-25  - 

SOU  RCE  MODULE  NAME 

26-31  - 

COUNT  OF  EXECUTIONS,  DECIMAL 

35-40  - 

DATE  EXECUTED,  MMDDYY 

41-50  - 

UNUSED 
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8.2  File  Structure  Deck 

STRUCTURE  TESTE  RF  . 


CLASSIFICATION  'UNCLASSIFIED'. 


NOTE  : 

This  d at  a 

file  is  the  statistics  data  file  for  the 

TEST360  file.  The  file  will 

utilize  the  transactions 

output  by 

the  P lie  A ns  ly  si  s 

Statistics  capability. 

NOTE: 

Tha  following  elements  ire  used  for  record  control. 

EDIT 

DATE 

•OX/XX/XX'  . 

EDIT 

COUNT 

•XXXXXO'  . 

FIELD 

FILEN 

7 C ALPHA 

•FILE  NAHE' . 

FIELD 

COUP 

4 C ALPHA 

• COHPDN  ENT'  . 

FIELD 

SOURCE 

1 3 C ALPHA 

•COMPONENT  SOURCE  NAHE'. 

U ROUP 

RECID 

FILEN,COHP,  SOURCE  ALPHA  'RECORD  CONTROL' 

FIELD 

C NT  El 

6 JC  NUN ER  COUNT 

•COUNT  DP  EXECUTIONS'. 

FIELD 

ihon 

2 X NUHER . 

FIELD 

IDAY 

2 X NUHER. 

FIELD 

I YEAR 

2 X NUHER. 

3BOUP 

I DAT  E 

IHON,  IDAY,  IY  EAR 

DATE  'INITIAL  DATE'. 

FIELD 

LHON 

2 X NUHER. 

riELD 

LD  AY 

2 X NUNEB. 

PIELD 

LYEAR 

2 X NUHER. 

GROUP 

L D AT  E 

LHON, LDAY, LY  EAR 

DATE  'LATEST  DATE'. 

NOTE: 

The  following  field  is  used 

for  subset  control. 

FIELD 

PLDNAH 

8 CL  ALPHA 

•FIELD  NAHE'. 

FIELD 

SBTN 

3 1 ALPHA 

•SET  NUMBER ' . 

FIELD 

C NT  REF 

6 1 NUHER  COUNT  'COUNT  OF  REFERENCES'. 

FIELD 

U NO  N 

2 1 NUHER. 

FIELD 

UDAI 

2 1 NUHER. 

FIELD 

UYEAR 

2 1 NU  HE  R . 

GROUP 

UDATE 

UMON,U  DAY, UY  EAR 

DATE  'DATE  UTILITY  EXEC*. 

END. 
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B.3  PH  Logic  Statements 

The  following  logic  stateacn'’^  say  he  used  to  either 
generate  new  records  or  to  update  existing  records  on  the 
statistics  file. 

B.3.1  Z Transaction  Record  ~ Cosponeat  Execution 

Tha  ' C * transaction  iecr  d generated  by  the  coeponent 
•odif ications  yill  be  used,  by  this  logic  statement  to  build 
or  update  the  fixed  .iet  of  the  statistics  file.  The  logic 
statement  name  is-  in  co]  uin  one.  k report  '5TAT*  exists  in 
tha  fila. 


$ AS?,s?Ar , C,  SO 
|R EC .0,^,2  5, Cl  ,A 
SCorNV  ,2b,  31 
IDATE, 35,4  0 


POOL 

B NR 

NEW  REC 

COA 

IDATE,  •)#• 

BEQ 

RESET 

ADD 

ICOUNT,  CNTEX„  CBTBX 

HAL 

$ DAT  E,  LDATE 

PRT 

• LD  ATE  AND  COUNT  FIELD  UPDATED' 

NEW?  EC 

HLT 

HAL 

* HE  i RECORD  GENERATED  ',W23 

HAL 

1 RECID,  M 24/47 

PRT 

W1/47 

UPDATE 

HAL 

IDATE,  LDATE 

HAL 

IDATE, IDATE 

HHU 

J COUNT,  CNTEX 

RESET 

HLT 

pRr 

'LDATE  AND  IDATE  BLANK  , UP  DA  TED  ' 

BRA 

UPDATE 

END 

IE  tie  transaction  causes  a nee  record  to  be  generated, 
the  initial  date  (IDATE)  and  the  lost  recent  date  (IDA TE) 
will  be  set  to  the  date  in  the  transection  IDATE.  The  count 
cf  executions  (CNF  EX ) will  be  set  and  the  eessage  that  a new 
record  has  been  generated  with  the  record  ID  will  be  printed 
on  the  auxiliary  output  printer. 
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If  a new  record  was  not  generated,  the  count  of 
arjcutLsn-S  field  in  the  file  (CNTBX)  will  be  incceaented  by 
the  count  iu  the  transaction  record.  The  latest  date  will 
be  set  to  the  date  in  the  transaction  and  a sessage  will  be 
printed. 

B . 3 * 2 *S»  Traasaction  Record  - OTFLDSCN  Utility 

The  ’S'  transaction  record  generated  by  the  UTFLD5CN 
utility  will  be  used  to  build  or  update  periodic  set  one  of 
the  statistics  file. 

SASP.STAT,  S,  50 
I R EC  ID,  2,  2S,C1,  A 
SPIELDN,  26, 33, C2  ,1 
iS ET HO, 34, 36 
SCNTREP, 37,42 
JDAT  1,43,48 


POOL 

BHR 

NENRIC 

PCV 

JPIELDH,FLDHAH,HEWSS 

CO A 

10  AT  E,  0 DAT  E 

BE2 

DOPE 

CLR 

IDAP  E CLEAR  FIXED  SET  FIELDS 

CLR 

LD  ATE 

H NJ 

0,  CNTEI 

PRT 

•FIXED  SET  FIELDS  CLEARED* 

par 

‘PERIODIC  SET  OH  E UPDATED* 

PRT 

T2/36 

BRA 

HOF? 

DOPE 

PRT 

‘DUPLICATE  TFAHS  ACTION, HO  ACTION' 

PRT 

T2/36 

NCTREC 

a lf 

PRT 

•KEN  FIXED  SET  GENERATED  BT  S T f)AK>  ' 

NBWSS 

BSS 

PL  DRAB 

bcs 

$PIELDH,FLDNAB 

pft 

•HEN  SUBSET  GENERATED* 

PRT 

T2/3  6 

HOVE 

HAL 

ISETNO,  SETN 

BNU 

$CNTREF,CKTREP 

HAL 

$DATE,  UDAT  C 

E HD 
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If  this  logic  statement  causes  a q««  record  to  be 
generated,  a aessage  will  be  printed,  the  subset  will  be 
built  and  the  fiaLd  naie  will  be  noted  to  the  subset  control 
field.  The  fields  in  the  subset  will  be  filled  fro*  the 
transaction  record. 

If  it  is  not  a new  record,  a check  is  eade  for  the 
existence  of  a subset  containing  the  sane  field  v.ane.  If 
tba  subset  does  not  exist,  a subset  will  be  built.  If  it 
does  exist,  a comparison  is  Bade  between  the  date  in  the 
subset  and  in  the  transaction.  If  it  is  the  sane,  a 
duplicate  aessage  is  printed  and  no  further  action  is  taken. 

If  the  dates  are  not  the  saie,  the  fields  in  the  fixed  set 
are  cleared  and  the  fields  in  the  periodic  set  will  be 
updated  with  the  fields  in  the  transaction  record. 

B.4  RASP  Query 

Thi  following  saaple  qaery  will  retrieve  records  froa 
the  statistics  file. 

TITLE  STAT/01 . 

FILE  TESTERF. 

IF  COUP  EQ  PM  AND  CNTEX  NE  0. 

SORT  SOURCE. 

This  query  will  retrieve  all  FH  logic  statements  that 
have  had  both  *C*  and  'S'  transactions  entered.  If  no 
executions  have  been  set  in  the  record,  the  record  will  be 
onit  ted . 

B.5  OP  HIT 

The  following  FIT  will  he  used  with  the  previous  query 
to  foriat  the  output. 

CREATE  RIT  ID=5T ATRIT  STORE  PEBH=0LD 

FILE  TESTE  FP 

format  print 

HEADER  1 92  CLASSIF 

SPACE  2 

HEADER  2 95  ’TESTERF  STATISTICS  FILE  - FILE  A NALf  5 IS 

STATISTICS  CAPABILITY 
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HEADER  2 
SPACE  3 

1 32 

OPD  ATE 

OVER  FLOW  1 

8 

FILER 

OVERFLOW  1 

19 

CORP 

0 VERFLOWl 

.39 

SOtlFCE 

OV  ERFLON  1 
SPACE  2 

bl 

• (CONTINUED)  • 

OVERFLOW  2 

54 

• FIELD  NAME* 

OVER  PLOW  2 

69 

•SET  NO.  * 

OV  KRFLOW  2 

77 

• REF.  COUNT' 

LABEL1 

9 

•FILE  NANE* 

LADEL1 

21 

• CONPONENT* 

LABEL1 

90 

'SOURCE  STATEHE 

LABEL1 

59 

• n EC,  COUNT* 

LABEL1 

69 

•INITIAL  DATE* 

LAB  ELI 

85 

•LATEST  DATE* 

LABEL1 

1 01 

•DATE  RIEC.  • 

LINE1 

FIRST  1 

linei 

8 

FILER 

I INE  1 

19 

CON  P 

LINEI 

39 

SOURCE 

LINEI 

52 

CNTET 

LINEI 

bl 

I DA  IE 

LINEI 

84 

LDATE 

LINE  1 
SPACE  2 

1 00 

I'D  ATE 

LABEL2 

54 

•FIELD  NANE* 

LABEL2 

69 

•SET  NO.* 

LABEL2 

77 

• REF.  COUNT' 

LINE  2 

S3 

FLDNAN 

LINE2 

62 

SETN 

LINE  2 

75 

C NT  RE  F 

EJSCT  BEHEES  RECORDS  IP  SOURCE  COMPLETE 
TRAILER  1 92  CLASSIF 

r R AI LERI  1 26  ' PAGE' 

TRAILEFl  132  PAGE  NO 
END 

SOURCE  RETRIEVAL 

PUBLISH  R I TTD  =STATRI  T ANS1D=0001  CLASS*U  NCLASS  IFIED 
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CCTC  CODU5 


COP  I h5 


C124 
C124 
0’24  0 
C 3 0 0 
0 3 1 0 
C 3 1 1 
0 .3 1 2 
C31  3 
0 314 
0315 
c3i  0 
C 3 1 7 
C32o 
0 321 

0322 

0323 

0324 
032b 
<-34o 
0341 
0 341 
070  0 
0702 
070  3 
07  Ij  5 
0 710 
0720 
07  30 


( iicfcruncc ) 

( Oecorci  Cokjy ) - 
(COi\  for  CSC ) ~ 


('Iraxning) 


(,  .iiint^r-iinw  Contractor) 

(UtOC/vi  


(Vuc.i  oor  fUjjport) 


2 

1 

20 

1 

1 

1 

1 

1 

1 

1 

1 

1 

5 

1 

1 

1 

1 

1 

j 

S 

50 

1 

1 

1 

1 

2 

1 


OCA  COtiLii 


0100 1 

OHO 1 

0205  1 

05  30  1 

CO 00  1 
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Director  of  Administrative  Services,  Office  of  the  Joint 
Chiefs  of  Staff 

Attn:  Chief,  Personnel  Division,  Room  2A944,  The  Pentagon 

Washington,  D.C.  20301  1 

Director  for  Personnel,  J-l,  Office  of  the  Joint  Chiefs  of 
Staff,  Attn:  Chief,  Data  Service  Office,  Room  1B738C, 

The  Pentagon,  Washington,  D.C.  20301  1 

Director  for  Operations,  J-3,  Office  of  the  Joint  Chiefs 
Staff,  Attn:  Chief,  Data  Processing  Division,  Room  2C869, 

Tne  Pentagon,  V?ashingtor. , D.C.  20301  1 

Director  for  Operations , J-3,  Office  of  the  Joint  Chiefs 
of  Staff,  nctn:  P & AD,  Room  2B870,  '.'he  Pentagon, 

Wa suing ton,  D.C.  203ul  1 

Director  for  Operations,  J-3,  Office  of  the  Joint  Chiefs 
ut  Staff,  Attn:  Deputy  Director  for  Operations 
(keconnaisance  and  Electronic  Warfare)  Room  2D921, 

Tla-  Pentagon,  Washington,  D.C.  20301  -- — — 1 

Director  for  Logistics,  J-4,  Office  of  the  Joint  Chiefs 
of  Staff,  Room  2 E 8 2 8 , The  Pentagon,  Washington,  D.C. 

20301  1 

Chief,  Studies  Analysis  and  Gaming  Agency,  Attn:  Chief, 

Force  Analysis  Branch,  Room  1D928A,  The  Pentagon, 

Wasnington,  D.C.  20301  1 

Automatic  Data  Processing,  Liaison  Office,  National 
Military  Command  Center,  Room  2D9Q1A,  The  Pentagon, 
Washington,  D.C.  20301  1 

Automatic  Data  Processing  Division 
Supreme  headquarters  Allied  Powers,  Europe 

Attn:  SA  5<  P Branch,  APO  New  York  09055  1 

Defense  Civil  Preparedness  Agency,  Computer  Systems 
Division,  Room  3D317,  The  Pentagon,  Washington,  D.C. 

20  301  1 

Director,  Defense  Communications  Agency,  Office  of  ML ECU 
System  Engineering,  Attn:  Code  960T,  Washington,  D.C. 

20301  1 

Director,  Defense  Communications  Engineering  Center, 

Hybrid  Simulation  Facility,  1860  Wiehle  Avenue,  Reston, 

VA  220  7 0 1 
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Commander , Joint  Technical  Support  Activity 
Attn:  Chief,  Software  Operations  Division 

1860  Wiehlo  Avenue,  ncr.ton,  VA  22010 y 

Director,  DeCennc  Intelligence  Agency 
Attn:  DS  - 5C2 

Washington,  DC  20301 • ^ 

Co^ander-in-Chief , Pacific,  Attn:  J6311,  TPO  San 

Francisco,  96610 , 

Commando: -m-Chiof , Europe,  Attn:  Chief,  KUCOM  AD?  Systems  1 

Office  ( LC’.DP)  APO  Dow  York  09128 1 

Commander- in-Oh ief , US  Army  Europe  and  Seventh  Army 

Attn:  ODCS,  OPS  APO  Mew  York  09103 x 

Commanding  General,  US  Army  Forces  Command,  Attn:  Data 

Support  Division,  Building  206,  Fort  McPherson,  GA  30303 1 

Commander,  Fleet  Intelligence  Center,  Kurope,  Box  18, 

Naval  Air  Station,  Jnckronvj  lie , FL  32212 1 

Commanding  Officer,  Nival  Air  Engineering  Center,  Ground 
Support  Equipment  Dcpar  ti.iont. , St:  3M,  Building  76-1, 

Philadelphia,  PA  lc>112 j 

Command  ing  Officer,  Naval  Security  Croup  Command, 

3801  Nebraska  Avenue,  NW,  Attn:  GF22,  Washington,  DC 

20390 i 

Commanding  Officer,  Navy  ships  Farts  Control  Center 

Attn:  Code  712,  Mecho.nictburg , TA  1703S q 

Headquarters,  US  Marine  Corps,  Attn:  System  Design  and 

rrograiitni ng  Section  (itC-JSMD-7)  Washington,  DC  20300 g 

Commanding  Officer,  US  Army  Forces  Command  Intelligence 

Center,  Attn:  Al’IC-1  D,  Fort  Dragg,  NC  213307 j J 

Commander  , 1 1 S Amy  Foreign  Science  and  Technology  Center  j 

Attn:  A!  ;X:'-.I-CS , 220  Seventh  Street,  NK, 

Cli.ii  lottsvi  Ho,  VA  22312 ] 
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Commanding  Office)-,  OS  Army  Security  Agency,  Command 

Data  Systems  Activity  (CUSA)  Arlington  Hall  StoLion 

Arlington,  VA  22212 ^ 

Commanding  Officer,  US  Army  Security  Agency  Field 

Station  - Augsburg,  Attn:  1ALADP,  APO  New  York  09458 1 

Commander,  Fleet  Intelligence  Center,  Atlantic, 

Attn:  DPS,  Norfolk,  VA  2351  1 1 

Commander , Fleet  Intelligence  Center,  Pacific,  Box  1275 

FPO  San  Francisco,  96610 1 

Air  Force  Operations  Center,  Attn:  Systems  Division 

(XOOCSC)  Washington,  DC  20301 1 

Commander,  Armed  Forces  Air  Intelligence  Training  Center, 

Attn:  TIN  I -MIT , Lowry  AFB , CO  802  30 1 

Commander,  Air  Force  Data  Services  Center,  Attn:  Director 
of  System  Support,  V.’ashingtor,  DC  20330 1 

Commandcr-in-Chi ef , US  Air  Forces  in  Europe , ATTN:  ACDI 

APO  Mew  York  09332 1 

Commander,  USAF  Tactical  Air  Command,  Langley  APB, 

VA  23665 i 

Commander,  Space  and  Missile  Test  Center,  Attn:  (ROCA) 

Building  7000,  Vandenborg,  . FB,  CA  93d  37 1 

Naval  Air  Systems  Command,  Naval  Air  Station, 

Code  13000,  Jacksonville,  FL  32212 1 

Commanding  General,  US  Army  Computer  Systems  Command, 

Attn:  Support  Operations  Directorate,  Port  Scl'-oir, 

VA  1 

Defense  Documentation  Center,  Cameron  Station, 

Alexandria,  VA  22314 12 

TOTAL  171 
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